Сонар отказывается анализировать ERP

#1

в рамках pipeline, пытаемся Сонаром проанализировать код ERP, получаем ошибки 2х типов.
1й вариант ошибки (проверка падает через 19-23 минуты):
00:50:33 INFO: ------------------------------------------------------------------------
00:50:33 INFO: EXECUTION FAILURE
00:50:33 INFO: ------------------------------------------------------------------------
00:50:33 INFO: Total time: 16:18.477s
00:50:36 INFO: Final Memory: 1355M/1856M
00:50:36 INFO: ------------------------------------------------------------------------
00:50:36 ERROR: Error during SonarQube Scanner execution
00:50:36 ERROR: Caused by: GC overhead limit exceeded

2й вариант (Проверка падает через 45-53 минуты)
06:33:23 Exception in thread “CLEANUP_MANAGER” Exception in thread “LOG_FLUSHER” java.lang.OutOfMemoryError: Java heap space
06:33:23 java.lang.OutOfMemoryError: Java heap space
06:33:23 at java.util.ArrayList.iterator(Unknown Source)
06:33:23 at com.persistit.CleanupManager.poll(CleanupManager.java:179)
06:33:23 at com.persistit.CleanupManager.runTask(CleanupManager.java:88)
06:33:23 at com.persistit.IOTaskRunnable.run(IOTaskRunnable.java:144)
06:33:23 at java.lang.Thread.run(Unknown Source)
06:33:23 WARN: [JOURNAL_FLUSHER] WARNING Journal flush operation took 4�139ms last 8 cycles average is 517ms
06:33:25 INFO: ------------------------------------------------------------------------
06:33:25 INFO: EXECUTION FAILURE
06:33:25 INFO: ------------------------------------------------------------------------
06:33:25 INFO: Total time: 47:47.322s
06:33:28 INFO: Final Memory: 1354M/1839M
06:33:28 INFO: ------------------------------------------------------------------------
06:33:28 ERROR: Error during SonarQube Scanner execution
06:33:28 Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “JOURNAL_COPIER”
06:33:28
06:33:28 Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread “Report about progress of code analyzer”

Настройки Сонара
05:45:37 INFO: SonarQube Scanner 3.1.0.1141
05:45:37 INFO: Java 1.8.0_181 Oracle Corporation (64-bit)
05:45:37 INFO: Windows Server 2016 10.0 amd64
05:45:38 INFO: User cache: C:\Users\jenkins_console.sonar\cache
05:45:38 INFO: SonarQube server 7.1.0

Подскажите, из-за чего это может быть и что с этим можно сделать?

#2

Final Memory: 1355M/1856M

Вижу что забыли выделить память на ERP для sonar-scanera. Поэтому кстати и 43 минуты.

Фактически вы пытаетесь 5.5 миллионов строк (размер ERP) просунуть в 2 гигабайта оперативной памяти - если это первый старт.

В документации на плагин указаны рекомендуемые параметры для первого запуска (первого анализа).

#3

Постепенно добавляли Память, в итоге отработало нормально на 20ГБ, заняло 2ч34мин
2.4.5 уже 7 миллионов строк

#4

Походу процы виртуализированы и диски медленные.

Для первого анализа используется GIT BLAME - соответственно идет активная работа с процом и диском.

Если анализ делаете на Виндовс - проверьте кстати “Энергосбережение процов” - уберите сбалансированный режим, если вдруг еще не сделали

Какой кстати виртуализатор - VMware, HyperV, KVM, etc

#5

Это много - целевой средний показатель для первого анализа 43 минуты.

#6

Есть еще лайфхак (вычислил в июле)
учитывая что у вас 7.1 - можно использовать 9 и 10 JDK. Для управления версиями Java на машине мы с июля используем вот такое https://github.com/shyiko/jabba
Охренительно удобно - в том числе для EDT.

10-тая Java - это вот это например https://adoptopenjdk.net/

В августовский релиз включу это в инструкцию - получается очень быстро устанавливать и запускать сканер на клиенте.

@theshadowco - обрати внимание кстати: jabba тебе должна понравится

#7

более 7.5 было еще в 2016 году

#8

Стоп - ты погоди. На презентации может и столько было написано. Но бездушный Сонар давал в прошлом году 5.6 мегастрок (с регламентированными отчетами). А не знаю где они прячут еще 2 миллиона - может они еще СППР считали, так как он входит в поставку. НО - в ядре ERP в 2017 году НЕ было 7.5 миллиона строк,

#9

Ну наверно немного прибавили… Ктож их считать то будет)

#10

Гипервизор VmWare, ОС - Ubuntu 16.04 x64

#11

я вот что-то сомневаюсь, что эта цифра была с регл отчетами. Как бы мы вообще отчеты из анализа не выключали

#12

странно что ты сомневаешься. Было 2 фазы - без. регламетных отчетов для целей теста которую ты помнишь, и потом уже с регламетными отчетами - для продуктива.

На прошлой неделе как раз очередное было подключение на сервисах - без фильтра по регламентным отчетам.

#13

вы заставили меня задуматься, чтобы четко проверить - что там в реальности

Вот смотрите - редакция 2.4.5.33

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

Все так 7 миллионов честных

С регламентированными отчетами

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png1014×158 29.3 KB

#14

модуль интеграции с документооборотом они так и не пофиксили? Все еще рвется директивой?)

#15

всё также

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5
изображение.png764×203 49.7 KB

не хотят исправлять

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

#16

Добрый день, У нас продолжительность анализа ERP существенно больше чем 43 минуты, даже для не первичного


что нам можно сделать, чтобы ускорить анализ?

#17

Какое значение у переменной SONAR_SCANNER_OPTS?

#18

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -Xmx20G

#19

скиньте лог в личку - я точно пойму где у вас идет основная просадка по ресурсам.

Позавчера разбирался с вирутализатором с коэфциентом умножения “4”. Ядер выгляделоо как 8 а в реальности 2, да и модель ядра была 2,66 GHz с датой выхода 4 квартал 2007 года. Вообщем совершенно не удивительно что тормозило.