Настройка параметров JVM#

SonarQube запускает три JVM-процесса внутри одного Pod — Web server (UI и Web API), Compute Engine (фоновые задачи анализа) и Search component (встроенный Elasticsearch). У каждого из них свой бюджет -Xmx / -Xms. Значения по умолчанию подходят для небольших развертываний, но для более крупных проектов или при более высокой параллельности сканирования часто требуется больше heap для Web или Compute Engine, а heap для Search обычно приходится увеличивать синхронно с ростом числа проектов.

В этом руководстве показано, как задать параметры JVM отдельно для каждого процесса через SonarQube CR и как проверить, что изменения вступили в силу.

#Предварительные требования

• Запущенный экземпляр SonarQube, управляемый этим оператором.
• Доступ на редактирование пользовательского ресурса Sonarqube.
• Ограничения ресурсов контейнера в Pod SonarQube должны быть достаточно большими, чтобы вместить новый бюджет heap — увеличение -Xmx без повышения ограничения памяти Pod лишь переносит ошибку OOM на один уровень выше.

#Шаг 1 — Задайте параметры JVM в SonarQube CR

Отредактируйте SonarQube CR и добавьте параметры Java для каждого процесса в spec.helmValues.sonarProperties. Эти три имени свойств соответствуют трем процессам SonarQube один к одному:

Пример:

apiVersion: operator.alaudadevops.io/v1alpha1
kind: Sonarqube
metadata:
  name: <RELEASE>
  namespace: <NAMESPACE>
spec:
  helmValues:
    sonarProperties:
      sonar.web.javaOpts: "-Xmx1G -Xms128m -XX:+HeapDumpOnOutOfMemoryError -server"
      sonar.ce.javaOpts: "-Xmx2G"
      sonar.search.javaOpts: "-Xmx2G -Xms2G"

Примените изменения к CR. При следующем reconcile оператор применит их в ConfigMap SonarQube.

#Шаг 2 — Проверьте, что ConfigMap обновлен

Процесс SonarQube читает эти параметры из сгенерированного ConfigMap, имя которого заканчивается на -sonarqube-config. Перед перезапуском убедитесь, что новые значения присутствуют:

kubectl -n <NAMESPACE> get configmap <RELEASE>-sonarqube-config -o yaml \
  | grep -E "sonar\.(web|ce|search)\.javaOpts"

Если ключи по-прежнему содержат старые значения, подождите несколько секунд, пока оператор выполнит reconcile, и проверьте еще раз. Не переходите дальше, пока ConfigMap не будет содержать новые значения.

#Шаг 3 — Перезапустите Pod SonarQube

Параметры JVM считываются при запуске процесса, поэтому новые значения вступят в силу только после перезапуска:

kubectl -n <NAMESPACE> rollout restart deployment <RELEASE>-sonarqube
kubectl -n <NAMESPACE> rollout status deployment <RELEASE>-sonarqube

#Шаг 4 — Убедитесь, что запущенные JVM используют новые параметры

В UI SonarQube перейдите в Administration → System и разверните разделы Web, Compute Engine и Search. Каждый раздел показывает фактически используемые флаги JVM — убедитесь, что значения -Xmx и -Xms совпадают с теми, которые вы задали на шаге 1.

Из командной строки можно получить те же данные, просмотрев запущенные Java-процессы внутри Pod:

kubectl -n <NAMESPACE> exec <RELEASE>-sonarqube-xxxxx -- bash -lc \
  "ps -ef | grep -E '(WebServer|CeServer|elasticsearch)' | tr ' ' '\n' | grep -E '^-X(mx|ms)'"

Если новые флаги не отображаются, наиболее вероятная причина — был пропущен шаг 2: Pod был перезапущен до того, как ConfigMap обновился.

#Примечания

• О helmValues.jvmOpts / jvmCeOpts. В старой документации также упоминаются поля уровня chart jvmOpts и jvmCeOpts. В chart, поставляемом вместе с этим оператором, они сохранены для обратной совместимости, но в upstream-файле values помечены как устаревшие, и при одновременной настройке они явно переопределяются sonarProperties.sonar.web.javaOpts / sonar.ce.javaOpts. Для процесса Search аналогичного поля chart не существует — используйте sonarProperties.sonar.search.javaOpts. Для всех трех процессов предпочтительно использовать путь sonarProperties, чтобы конфигурация оставалась согласованной и не терялась при обновлениях chart.
• Держите -Xmx строго ниже ограничения памяти Pod. Грубое правило: sum(web + ce + search -Xmx) + 25% запас ≤ лимит памяти контейнера. Если задать heap так, что их сумма достигает лимита или превышает его, Pod будет завершаться по OOM, когда JVM законно использует весь свой heap вместе с off-heap памятью.
• Heap Search. Elasticsearch работает лучше всего, когда -Xms равен -Xmx. Если задать только -Xmx для sonar.search.javaOpts, heap будет изменять размер во время выполнения, что вызывает кратковременные задержки при больших анализах.
• HeapDumpOnOutOfMemoryError. При расследовании периодических сбоев OOM для процессов Web и Compute Engine рекомендуется добавить -XX:+HeapDumpOnOutOfMemoryError. Dump будет записан в рабочий каталог SonarQube внутри Pod; скопируйте его с помощью kubectl cp до того, как Pod будет пересоздан.