I'm trying to upgrade our SonarQube from 6.7.4 to 7.9.3 but when execute:
SONARQUBE_HOME/bin/linux-x86-64/sonar.sh start
I got the following in the SONARQUBE_HOME/logs/sonar.log file:
--> Wrapper Started as Daemon
Launching a JVM...
JVM exited while loading the application.
java.lang.OutOfMemoryError: Java heap space
Dumping heap to java_pid30868.hprof ...
Heap dump file created [8502105 bytes in 0.031 secs]
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1470)
at java.base/java.util.zip.ZipFile$Source.<init>(ZipFile.java:1274)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
at java.base/java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:727)
at java.base/java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:247)
at java.base/java.util.zip.ZipFile.<init>(ZipFile.java:177)
at java.base/java.util.jar.JarFile.<init>(JarFile.java:348)
at java.base/jdk.internal.loader.URLClassPath$JarLoader.getJarFile(URLClassPath.java:813)
at java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:758)
at java.base/jdk.internal.loader.URLClassPath$JarLoader$1.run(URLClassPath.java:751)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:750)
at java.base/jdk.internal.loader.URLClassPath$JarLoader.<init>(URLClassPath.java:725)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:493)
at java.base/jdk.internal.loader.URLClassPath$3.run(URLClassPath.java:476)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:475)
at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:444)
at java.base/jdk.internal.loader.URLClassPath$1.next(URLClassPath.java:340)
at java.base/jdk.internal.loader.URLClassPath$1.hasMoreElements(URLClassPath.java:351)
at java.base/jdk.internal.loader.BuiltinClassLoader$1.hasNext(BuiltinClassLoader.java:355)
at java.base/jdk.internal.loader.BuiltinClassLoader$1.hasMoreElements(BuiltinClassLoader.java:363)
at java.base/java.lang.CompoundEnumeration.next(ClassLoader.java:3032)
at java.base/java.lang.CompoundEnumeration.hasMoreElements(ClassLoader.java:3041)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.nextProviderClass(ServiceLoader.java:1202)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1220)
at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1264)
at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1299)
at java.base/java.util.ServiceLoader$ProviderSpliterator.tryAdvance(ServiceLoader.java:1483)
at java.base/java.util.Spliterator.forEachRemaining(Spliterator.java:326)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
JVM Restarts disabled. Shutting down.
<-- Wrapper Stopped
SONARQUBE_HOME/conf/sonar.properties:
sonar.web.javaOpts=-server -Xmx4096m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
sonar.ce.javaOpts=-server -Xmx4096m -Xms512m -XX:+HeapDumpOnOutOfMemoryError
OpenJDK 11.0.7
If you need more info please let me know. Thanks a lot.
We found the issue.
The "wrapper.java.maxmemory" value in the "DO NOT EDIT THE FOLLOWING SECTIONS" part of the "SONARQUBE_HOME/conf/wrapper.conf" file was changed by mistake from "32" (The SonarQube starts pretty well) to "8" (OutOfMemoryError).
Related
I am trying to install SonarQube 7.9.1 in my windows 10 machine. And when I run StartSonar.bat on the command line, I get the below error:
Exception in thread “main” java.lang.NoClassDefFoundError:com/fasterxml/jackson/dataformat/yaml/YAMLParser”.
This is a fresh install and never had any previous version of SonarQube. As a prerequisite I installed JDK as below:
openjdk version “11” 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
Is there any other prerequisite other than JDK to be installed? Can I know any other reason?
These are the logs:
2019.09.24 16:57:23 INFO app[o.s.a.AppFileSystem] Cleaning or creating temp directory C:\Team\Sonarqube\temp
2019.09.24 16:57:23 INFO app[o.s.a.es.EsSettings] Elasticsearch listening on /127.0.0.1:9001
2019.09.24 16:57:23 INFO app[o.s.a.ProcessLauncherImpl] Launch process[[key=‘es’, ipcIndex=1, logFilenamePrefix=es]] from [C:\Team\Sonarqube\elasticsearch]: C:\Program Files\Java\jdk-11\bin\java -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly -Des.networkaddress.cache.ttl=60 -Des.networkaddress.cache.negative.ttl=10 -XX:+AlwaysPreTouch -Xss1m -Djava.awt.headless=true -Dfile.encoding=UTF-8 -Djna.nosys=true -XX:-OmitStackTraceInFastThrow -Dio.netty.noUnsafe=true -Dio.netty.noKeySetOptimization=true -Dio.netty.recycler.maxCapacityPerThread=0 -Dlog4j.shutdownHookEnabled=false -Dlog4j2.disable.jmx=true -Djava.io.tmpdir=C:\Team\Sonarqube\temp -XX:ErrorFile=…/logs/es_hs_err_pid%p.log -Xms512m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError -Delasticsearch -Des.path.home=C:\Team\Sonarqube\elasticsearch -Des.path.conf=C:\Team\Sonarqube\temp\conf\es -cp lib/* org.elasticsearch.bootstrap.Elasticsearch
2019.09.24 16:57:23 INFO app[o.s.a.SchedulerImpl] Waiting for Elasticsearch to be up and running
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
2019.09.24 16:57:23 INFO app[o.e.p.PluginsService] no modules loaded
2019.09.24 16:57:23 INFO app[o.e.p.PluginsService] loaded plugin [org.elasticsearch.transport.Netty4Plugin]
Exception in thread “main” java.lang.NoClassDefFoundError: com/fasterxml/jackson/dataformat/yaml/YAMLParser
at org.elasticsearch.common.xcontent.XContentType$3.xContent(XContentType.java:94)
at org.elasticsearch.common.xcontent.XContentFactory.xContent(XContentFactory.java:135)
at org.elasticsearch.common.settings.Settings$Builder.loadFromStream(Settings.java:1128)
at org.elasticsearch.common.settings.Settings$Builder.loadFromPath(Settings.java:1112)
at org.elasticsearch.node.InternalSettingsPreparer.prepareEnvironment(InternalSettingsPreparer.java:100)
at org.elasticsearch.cli.EnvironmentAwareCommand.createEnv(EnvironmentAwareCommand.java:95)
at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:86)
at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:124)
at org.elasticsearch.cli.Command.main(Command.java:90)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:116)
at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:93)
Caused by: java.lang.ClassNotFoundException: com.fasterxml.jackson.dataformat.yaml.YAMLParser
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:582)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
… 11 more
We have a legacy application which is build using spring3 and java 7 and it was running on Jboss 6. Recently we have upgraded the jboss server from version 6 to version 7.1.3 with spring version from 3.0 to 4.3.1 and java from Oracle 1.7.0_60-b19 to Open java-1.8.0-openjdk.x86_64 1:1.8.0.191.b12-0.el6_10.
After the upgrade we are started getting error java.lang.OutOfMemoryError: GC overhead limit exceeded.
There is no code change in application and the linux box is same as it was there for Jboss 6.
We have analysed the heap dump shared by the production linux team. we used the JvisualVM and Eclipse Memory analyzer and it is pointing to below two possible leakage susspect.
1. io.undertow.server.session.InMemorySessionManager$SessionImpl
2. org.jboss.vfs.spi.JavaZipFileSystem
Linux team has copied the same configuration from jBoss 6 to jBoss 7. The configuration is -
export JAVA_OPTS="$JAVA_OPTS -Xms4096m -Xmx4096m -XX:MaxPermSize=1024m -Xverify:none -Dorg.jboss.resolver.warning=true -Djboss.modules.system.pkgs=com.sun.crypto.provider -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi.dgc.server.gcInterval=1800000 -server -XX:+DoEscapeAnalysis -XX:+UseCompressedOops -XX:+UseParallelGC -XX:+UseParallelOldGC -Dcom.ibm.mq.cfg.useIBMCipherMappings=false -Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Stack=true -Dsun.security.ssl.allowUnsafeRenegotiation=true -Dorg.apache.jasper.compiler.Parser.STRICT_WHITESPACE=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/logs/EAP/"
Increasing the heap space (young generation, eden storage) is the only option?
While running my test after some time i got below error like "java.lang.OutOfMemoryError: Java heap space"
Could some one please help me how to increase java heap space for jmeter.
2018-08-16 18:57:07,765 ERROR o.a.j.JMeter: Uncaught exception:
java.lang.OutOfMemoryError: Java heap space
2018-08-16 18:57:14,745 INFO o.a.j.t.JMeterThread: Thread finished: Thread Group 1-6
2018-08-16 18:57:14,745 ERROR o.a.j.JMeter: Uncaught exception:
java.lang.OutOfMemoryError: Java heap space
For JMeter 4.0 default settings are:
-Xms1g -Xmx1g -X:MaxMetaspaceSize=256m
For Windows you can amend them in 2x times:
set HEAP="-Xms2g -Xmx2g -X:MaxMetaspaceSize=512m" && jmeter.bat
For Linux/Unix/Macosx:
export HEAP="-Xms2g -Xmx2g -X:MaxMetaspaceSize=512m" && ./jmeter.sh
Also make sure you're following JMeter Best Practices and recommendations from the 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure
I'm using Sonarqube community version. I'm getting the following error,
Exception in thread "LOG_FLUSHER" Exception in thread "CHECKPOINT_WRITER" java.lang.OutOfMemoryError: Java heap space
at java.util.ArrayList.iterator(ArrayList.java:840)
at java.util.Collections$SynchronizedCollection.iterator(Collections.java:2031)
at com.persistit.Persistit.pollAlertMonitors(Persistit.java:2285)
at com.persistit.Persistit$LogFlusher.run(Persistit.java:192)
java.lang.OutOfMemoryError: Java heap space
at java.util.HashMap$Values.iterator(HashMap.java:968)
at com.persistit.Persistit.earliestDirtyTimestamp(Persistit.java:1439)
at com.persistit.CheckpointManager.pollFlushCheckpoint(CheckpointManager.java:271)
at com.persistit.CheckpointManager.runTask(CheckpointManager.java:301)
at com.persistit.IOTaskRunnable.run(IOTaskRunnable.java:144)
at java.lang.Thread.run(Thread.java:748)
WARNING: WARN: [JOURNAL_FLUSHER] WARNING Journal flush operation took 7,078ms last 8 cycles average is 884ms
INFO: ------------------------------------------------------------------------
INFO: EXECUTION FAILURE
INFO: ------------------------------------------------------------------------
INFO: Total time: 1:17.852s
ERROR: Error during SonarQube Scanner execution
ERROR: Java heap space
ERROR:
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "CLEANUP_MANAGER"
INFO: Final Memory: 40M/989M
INFO: ------------------------------------------------------------------------
The SonarQube Scanner did not complete successfully
I have Changed the size in sonar.properties, still I'm facing the same problem. How to solve this.
sonar.web.javaOpts=-Xmx4G -Xms2048m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts =-Xmx4G -Xms2048m -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaOpts=-Xmx4G -Xms2048m -XX:+HeapDumpOnOutOfMemoryError
What you've changed are the settings that allocate memory to SonarQube itself.
What you need to change is the setting that allocates memory to the analysis process. You haven't said which analyzer you're using, so the details will vary a little, but
for SonarQube Scanner export SONAR_SCANNER_OPTS="-Xmx512m"
for SonarQube Scanner for Maven export MAVEN_OPTS="-Xmx512m"
Large files in Project cause this problem, for me a 50MB XML file gives this error and this file was not important to the analysis process. I excluded this file in the configuration file (SonarQube.Analysis.xml) and the problem was solved
I am running SonarQube 5.5 with the following wrapper config settings.
wrapper.java.initmemory=3
wrapper.java.maxmemory=4096
I am still getting the following stack trace, this project has run successfully with sonarqube 5.3.
2016.05.09 11:14:09 INFO [o.s.s.c.s.ComputationStepExecutor] Compute coverage measures | time=105ms
2016.05.09 11:14:09 INFO [o.s.s.c.s.ComputationStepExecutor] Compute comment measures | time=120ms
2016.05.09 11:14:14 INFO [o.s.s.c.s.ComputationStepExecutor] Copy custom measures | time=5667ms
2016.05.09 11:14:15 INFO [o.s.s.c.s.ComputationStepExecutor] Compute duplication measures | time=424ms
2016.05.09 11:14:26 ERROR [o.s.s.c.c.ComputeEngineContainerImpl] Cleanup of container failed
java.lang.OutOfMemoryError: GC overhead limit exceeded
2016.05.09 11:14:26 ERROR [o.s.s.c.t.CeWorkerCallableImpl] Failed to execute task AVSWNiXkOySW07vtMalp
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.util.Arrays.copyOfRange(Arrays.java:3664) ~[na:1.8.0_45]
at java.lang.StringBuffer.toString(StringBuffer.java:671) ~[na:1.8.0_45]
at java.io.StringWriter.toString(StringWriter.java:210) ~[na:1.8.0_45]
at org.apache.commons.lang.Entities.escape(Entities.java:838) ~[commons-lang-2.6.jar:2.6]
at org.apache.commons.lang.StringEscapeUtils.escapeXml(StringEscapeUtils.java:620) ~[commons-lang-2.6.jar:2.6]
at org.sonar.server.computation.step.DuplicationDataMeasuresStep$DuplicationVisitor.appendDuplication(DuplicationDataMeasuresStep.java:129) ~[sonar-server-5.5.jar:na]
Memory adjustments must be made in sonar.properties:
sonar.web.javaOpts (for Web Server JVM)
sonar.ce.javaOpts (for Compute Engine JVM)
sonar.search.javaOpts (for JVM running ElasticSearch).
In your case the memory exception occurs in a background task so it relates to Compute Engine (see SonarQube architecture for more insight).
Settings in wrapper.conf are not relevant here and should be left untouched (hence the # DO NOT EDIT THE FOLLOWING SECTIONS warning in the file).