Настройка сервера SonarQube

Я это проходил. Оказывается за серверной частью тоже нужно поглядывать. Шутка.

А если серьезно, смотри, если база на 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 сразу :wink:
  • папка data/es6 - если превышает 15 Gb, мигрируйте на выделенный ELK с разбиением на шарды по 10Gb на ноду.

База PG

еженедельно делайте

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 и запусти сервер. Неизвестно что у тебя тебя там накопилось
3 Симпатий

с него начнем) будем тестить по одной операции за итерацию, чтоб отследить, от чего толк будет

Из логов ещё можно вытащить время каждой операции в CE. Он отдельно пишет про расчёт метрик, про сохранение ишузов, про доп расчёт копипасты, про обновление индексов и тд. И на каждой операции тайминг в ms.

Чтобы такое получить - нужно перезапускать сервер в режиме DEBUG логов.

Никита, наверно, про сообщения типа таких:
2019.03.27 15:29:24 INFO ce[AWm_BAXwaYTcMzjy27_-][o.s.c.t.s.ComputationStepExecutor] Persist live measures | insertsOrUpdates=781634 | status=SUCCESS | time=1638573ms

Они в INFO выводятся

1 Симпатия

А. Вы про это. Я просто уже привык к DEBUG вызову в случае отладки.
Из последнего - это эксперименты с размером сокета JDBC адаптера к PG.