Я это проходил. Оказывается за серверной частью тоже нужно поглядывать. Шутка.
А если серьезно, смотри, если база на PostgreSQL и сервера SonarQube на linux нужно сделать несколько вещей:
- поменять XMS и XMX для ELK на одинаковое значение
-Xmx4000m -Xms4000m
, чтобы не тратилось время ELK на аренду памяти из кучи (это если на пальцах)
рекомендуемый вариант нами
sonar.search.javaOpts=-server -Xmx4000m -Xms4000m -Djna.nosys=true \
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 \
-XX:+UseCMSInitiatingOccupancyOnly -XX:+HeapDumpOnOutOfMemoryError
- изменить объем памяти на процесс и количество открытых файлов на сервере
sysctl -w vm.max_map_count=262144
sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
Тюнниг
- папка temp - для linux в tmpfs сразу
- папка data/es6 - если превышает 15 Gb, мигрируйте на выделенный ELK с разбиением на шарды по 10Gb на ноду.
База PG
еженедельно делайте
- бэкап
- сразу после бэкапа делается vaccuumdb https://postgrespro.ru/docs/postgrespro/9.6/app-vacuumdb
sudo su postgres
vacuumdb -d sonardb -f -z -F
Отдельно про JDK
- Сонаровцы это скрывают но серверная часть прекрасно работает на JDK 10,11 и теперь еще на 12-той.
Весь этот комплекс мер позволит ускорить работу сервера, а точнее Compute Engine вне зависимости от языка.
И собственно рано или поздно с этими настройками придется столкнутся, причина в рефакторинге самого ядра в предверии выхода LTS версии.
Если подытожить - если наблюдаешь замедление CE, то:
- проверь XMX, XMS для ELK
- сделай vaccuumdb для PG, или analyze для MSSQL (какбудто это база 1С)
- если сервер на linux (НЕ в докере) проверь sysctl
- для чистоты - потуши сервер, очисти все внутри temp и запусти сервер. Неизвестно что у тебя тебя там накопилось