Сервер БД Oracle использует почти всю память во время сканирования SonarQube 6.7.5

Question

Использование Sonar 6.7.5 с подключением JDBC к Oracle 12c.Версия драйвера 12.2.0.1.0.Java JDK 1.8.0_111.

Выполнение mvn sonar:sonar, указание только небольшой части исходного кода с использованием соответствующего переключателя, поскольку иногда требуется минут для обработки каждого файла , и это, вероятно, связано с тем, что использование памяти сервером базы данных составляет 96%.Не помогает, что большая часть этого кода написана очень плохо (сложный унаследованный код со многими участниками и множеством проблем).

Где вы порекомендуете мне сначала посмотреть?Я пробовал инструменты SQLDeveloper для мониторинга активности, но ничего не зарегистрировано.База данных Oracle находится на сервере, отличном от того, где я запускаю SonarQube.

Это система, в которой я не могу копировать файлы, но я могу при необходимости транскрибировать настройки памяти Java или другие данные.Также посоветуйте, пожалуйста, как регистрировать файлы, которые я мог проверить.

Другие данные со страницы администрирования SonarQube:

Состояние JVM вычислительного движка

Максимальная память = 1963 МБ

Свободная память = 1649 МБ

Средняя загрузка системы = 146,0% (top показывает высокую скорость процессора, но не такую ​​высокую) Количество рабочих = 1

Должен ли я отключить некоторые правила и посмотреть, поможет ли это?

Answer 1

В 6.7 средство анализа не имеет прямого соединения с базой данных, поэтому никакая настройка базы данных не повлияет на минуты для обработки каждого файла , независимо от того.

Я думаю, что можно ожидать, что сканер SonarJava изо всех сил пытается разобрать сложные файлы, так как эти файлы будут затруднять работу механизма символьного выполнения (который включает, например, правила обнаружения нулевых указателей).Я бы посоветовал вам запускать задания анализа на более мощной машине, если вы можете - больше ЦП, больше памяти, выделенной для бегуна Maven.

Отключение правил в вашем профиле качества также может помочь, особенно если некоторые из нихне имеет отношения к вашей кодовой базе прямо сейчас.Вашей команде может быть полезно принять прогрессивный подход к улучшению качества кода: начать с подмножества правил высокой важности, правил с высокой степенью воздействия, сосредоточиться на устранении утечек (то есть избежать появления новых ошибок) и реорганизовать существующий код, чтобы уменьшить когнитивную сложность, а затем поднимите планку, включив другие правила позже.