Фоновые задачи SonarQube выполняются за 4 часа

Question

Мы модернизируем наш SonarQube с 4.5.X до 5.6.X, вычислительный движок - это новая концепция, и на бумаге она довольно тонкая. Но когда положено на работу, это мало что дает! помогите мне пройти, если вы сделали это

Я выбираю тестовые проекты, которые были отсканированы за 4 минуты с помощью SonarQube 4.5.4. Теперь начальное сканирование с использованием (Gradle) сканера занимает 3 минуты. А фоновые задачи CE выполняются вечно, из тестовых проектов: первый завершен за 183 минуты, другой за 263 минуты, третий все еще выполняется.

Очевидно, я начал копать и увидел вопрос о переполнении стека: фоновые задачи Sonarqube выполнялись вечно и увеличивали объем памяти, указанный в ответе, но он не работает для меня.

sonar.ce.javaOpts=-Xmx4096m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
sonar.ce.workerCount=5

Хотя количество рабочих равно 5, я не выполняю параллельные задачи сейчас. Из журналов выполненных работ я могу видеть некоторую тревожную информацию о времени!

2018.02.13 16:56:07 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute complexity measures | time=335ms
2018.02.13 16:56:07 INFO  [o.s.s.c.s.ComputationStepExecutor] Load measure computers | time=6ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   Execution time for each component visitor:
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LoadComponentUuidsHavingOpenIssuesVisitor | time=2483ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - IntegrateIssuesVisitor | time=15743879ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - CloseIssuesOnRemovedComponentsVisitor | time=0ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - QualityModelMeasuresVisitor | time=143ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - NewQualityModelMeasuresVisitor | time=73ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LastCommitVisitor | time=4ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - MeasureComputersVisitor | time=25ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ComputationStepExecutor] Execute component visitors | time=15746700ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute measure variations | time=3290ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute Quality Gate measures | time=54ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute Quality profile measures | time=25ms
2018.02.13 21:18:38 INFO  [o.s.s.c.s.ComputationStepExecutor] Generate Quality profile events | time=33ms
2018.02.13 21:18:38 INFO  [o.s.s.c.s.ComputationStepExecutor] Generate Quality gate events | time=6ms

Выполнить компонент посетителя, в частности IntegrateIssuesVisitor занимает много времени, 262 минуты из 263 минут, необходимых для исполнения. Как этого избежать?

Я не вижу никакой опции отключения межпроектного анализа, это связано с этим?

Дополнительная информация: использую Oracle DB

[Обновление] Вычеркнуло проклятие на СЕ. Мой плохой, CE это круто! Теперь некоторые проекты анализируются и публикуются за 3 секунды!

Answer 1

Решено!

Это было связано с базой данных, как указывалось в обсуждениях групп Google SonarQube.

Из https://docs.sonarqube.org/display/PLUG/Managing+Compute+Engine+Performance, ясно, что производительность Compute Engine связана с,

• база данных
• дисковый ввод / вывод
• сеть
• куча
• ЦПУ

Наше потребление памяти и использование процессора всегда были минимальными, поэтому сразу же мы исключили два последних. Но мы еще не знали, что было не так, если что-либо журналы CE бесполезны во всех отношениях, так как уровень журнала не применяется к журналам CE, у вас есть только INFO без уровней DEBUG или TRACE. Тем не менее мы поняли намек,

INFO  [o.s.s.c.s.ExecuteVisitorsStep]   Execution time for each component visitor:
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LoadComponentUuidsHavingOpenIssuesVisitor | time=58ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - IntegrateIssuesVisitor | time=41147606ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - CloseIssuesOnRemovedComponentsVisitor | time=1ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - QualityModelMeasuresVisitor | time=206ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - NewQualityModelMeasuresVisitor | time=119ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LastCommitVisitor | time=6ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - MeasureComputersVisitor | time=29336ms

IntegrateIssuesVisitor занимал невероятное количество времени, чтобы выполнить, журнал был только тем информативным, и часть почему была все еще загадкой. Поэтому мы решили выкопать код, слава богу, что SonarQube с открытым исходным кодом, но достаточно скоро, или команда DBA позвонила нам, почему наш запрос ведет себя так плохо. И это застряло у нас, по индексам мы проанализировали таблицы транзакций Sonar и у нас все хорошо.

tl; dr: обновляйте статистику таблицы, чтобы оптимизация всегда работала в вашу пользу. Проанализируйте таблицы.