Я использую Sonar Runner 2.2 и установить SONAR_RUNNER_OPTS=-Xmx8000m, но я получаю следующее сообщение об ошибке:Невозможно выполнить Sonar: Вызванный: Java куча пространства
Final Memory: 17M/5389M
INFO: ------------------------------------------------------------------------
ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: Java heap space
Как это может быть?
Если вы разрешаете пространство кучи расти до 8000 м, это не означает, что у вас всегда будет достаточно физической памяти, чтобы добраться туда, как и в вашей операционной системе, которая также потребляет память. Например, если на вашем компьютере имеется только «8 ГБ оперативной памяти», вполне вероятно, что кучное пространство никогда не сможет достичь максимально возможного значения.
BTW, я не знаю, что вы пытаетесь проанализировать, но я никогда не видел, чтобы кто-то требовал так много памяти для анализа проекта.
Машина имеет 24 ГБ оперативной памяти. Проект имеет более чем 80 000 LOC и много нарушений. Я попробую еще раз с sonar.findbugs.effort меньше Max. –
Что вы можете сделать, так это использовать более легкий профиль качества для начала. Выполнение анализа со всеми доступными правилами нередко потребляет больше памяти - и это не поможет вам больше, поскольку копать в результатах будет очень сложно. –
FYI, с Sonar 3.6 это место памяти, когда были решены миллионы проблем: http://jira.codehaus.org/browse/SONAR-4360. –
У меня была такая же проблема, и я нашел совсем другое решение, возможно потому, что я не верю ни одному из предыдущих ответов/комментариев. С 10 миллионами строк кода (это больше кода, чем в истребителе F16), если у вас есть 100 символов в строке (сумасшедший размер), вы можете загрузить всю базу кода в 1 ГБ памяти. Простая математика. Почему 8 ГБ памяти не удается?
Ответ: Поскольку сканер сообщества Sonar C++, похоже, имеет ошибку, где он берет ЛЮБОЙ файл с буквой «c» в его расширении. Это включает в себя .doc, .docx, .ipch и т. Д. Следовательно, причина, по которой у него заканчивается память, заключается в том, что она пытается прочитать файл, который, по его мнению, составляет 300 Мб чистого кода, но на самом деле его следует игнорировать.
Решение: найдите расширения, используемые всеми файлами в вашем проекте (see here).
Затем добавить эти другие расширения, как исключения в файле sonar.properties:
sonar.exclusions=**/*.doc,**/*.docx,**/*.ipch
Затем установите свои пределы памяти обратно в обычных количествах:
%JAVA_EXEC% -Xmx1024m -XX:MaxPermSize=512m -XX:ReservedCodeCacheSize=128m %SONAR_RUNNER_OPTS% ...
я столкнулся с той же проблемой во время выполнения теста случаев. С помощью Visuval VM проанализировано распределение памяти min и max в PermGen во время выполнения тестовых примеров и установлено, что он выделяет 80 МБ в PermGen. Следовательно, то же самое можно управлять через pom.xml в разделе свойств следующим образом.
<properties>
<argLine>-XX:PermSize=256m -XX:MaxPermSize=256m</argLine>
</properties>
Этот <argLine> тег, мы можем использовать либо в <maven-surefire-plugin> или в <properties>. Преимущество использования в разделе состоит в том, что одна и та же конфигурация может использоваться как тестовыми, так и сонарными. См. Ссылку here.
использование аргументов VM как -Xms512m -Xmx1024m – swamy