it happened in my vps.
[root#kunphen ~]# free -m
total used free shared buffers cached
Mem: 12067 87 11980 0 0 0
-/+ buffers/cache: 87 11980
Swap: 0 0 0
[root#kunphen ~]# java -version
Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
when I change it to "java -Xms16m -Xmx16m -version",it work.
I try many times.Its largest size is 22m,but my memory also have many free zone.
run it like this:
_JAVA_OPTIONS="-Xmx384m" play <your commands>
or play "start 60000" -Xms64m -Xmx128m -server
Related
I'm been trying to build LinageOS 18.1 but keep running into
OutOfMemoryError : Java Heap Space
I've increased the heap size with -Xxm25g and I can confirm it with java -version that the new heap size is indeed picked up by java, which shows Picked up _JAVA_OPTIONS: -Xxm25g
I've also setup a /swapfile size of 40GB
I have an 8GB RAM iMac with Ubuntu 18.04.6 on VMWare Fusion, using 4 processor
No matter how much -Xxm size I increase(even tried -Xxm50g), it still always errors out at this point of the build process :
//frameworks/base:api-stubs-docs-non-updatable metalava merged [common]
OutOfMemoryError : Java Heap Space
Is there a way to tweak the build process somewhere to get it to build?
I've read elsewhere that reducing the processor might also help, so I've also tried to reduce the no. processor to just 1 with brunch -j1 <target_name> but that doesn't work either as I believe Lineage uses the full available {n proc} so it's no accepting the -j argument. Is there a way to tell brunch to use just 1 processor?
I know an 8GB RAM is not the ideal build setup but I've read elsewhere it's possible. Thanks for any pointers help
Here's the memory statistics right before, during and after the failure :
dev#ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 7.4G 3.9G 2.5G 5.1M 1.0G 3.2G
Swap: 49G 495M 49G
dev#ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 7.4G 3.9G 2.4G 5.1M 1.0G 3.2G
Swap: 49G 495M 49G
dev#ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 7.4G 4.2G 2.0G 5.1M 1.2G 3.0G
Swap: 49G 495M 49G
dev#ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 7.4G 4.2G 2.0G 5.1M 1.2G 2.9G
Swap: 49G 495M 49G
dev#ubuntu:~$ free -h
total used free shared buff/cache available
Mem: 7.4G 4.4G 1.6G 5.1M 1.4G 2.7G
Swap: 49G 495M 49G
Background: Since the past few days, my linux development machine Java services one by one by the system kill, I looked at the system logs are OOM caused. Now I can't start the java process if I set the initial heap too large.
I can't see with the usual troubleshooting means, the development machine is a virtual machine (I don't think I can exclude the problem of the physical machine where the virtual machine is located, my colleague's machine and I applied at the same time, also have this problem), the total memory is about 6G, buff/cache + free total of about 5G. Thank you all for your help.
The crash logs at startup are in the attachment, and the system information and jdk information are in there.
enter link description here
Start-up log:
[~ jdk1.8.0_281]$java -Xms1000m -version
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000a5400000, 699400192, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 699400192 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /tmp/hs_err_pid7617.log
Memory usage is as follows:
[~ jdk1.8.0_281]$free -h
total used free shared buff/cache available
Mem: 5.7G 502M 213M 4.6G 5.0G 328M
Swap: 0B 0B 0B
The io situation is as follows:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
vda 0.03 2.77 0.84 2.80 48.95 97.58 80.57 0.05 22.14 65.48 9.22 0.55 0.20
scd0 0.00 0.00 0.00 0.00 0.01 0.00 66.96 0.00 0.34 0.34 0.00 0.24 0.00
This is my scenario:
SWAP Memory avaiable: 4GB
Linux
I'm getting these warnings:
Java HotSpot(TM) 64-Bit ServerVM warning: ignoring option MaxPermSize=1024m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000540000000, 7158628352, 0) failed; error='Cannot allocate memory' (errno=12)
Also this error:
There is insufficient memory for the Java Runtime Environment to continue.
Native memory allocation (mmap) failed to map 7158628352 bytes for committing reserved memory.
An error report file with more information is saved as:
/opt/apache-tomcat-8.0.28/hs_err_pid8656.log
ram memory in my machine:
total used free shared buffers cached
Mem: 7986 7839 147 0 94 1390
-/+ buffers/cache: 6354 1632
Swap: 4095 3 4092
WARNING: An attempt was made to authenticate the locked user "root"..
I'm trying to run jcstress 0.5, but I'm getting an error:
Error: VM option 'StressLCM' is develop and is available only in debug version of VM.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Full log:
Probing what VM modes are available:
(failures are non-fatal, but may miss some interesting cases)
----- [OK] [-Xint]
----- [OK] [-XX:TieredStopAtLevel=1]
----- [OK] []
----- [N/A] [-XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]
Error: VM option 'StressLCM' is develop and is available only in debug version of VM.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
----- [OK] [-XX:-TieredCompilation]
----- [N/A] [-XX:-TieredCompilation, -XX:+UnlockDiagnosticVMOptions, -XX:+StressLCM, -XX:+StressGCM]
Error: VM option 'StressLCM' is develop and is available only in debug version of VM.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Initializing and probing the target VM:
(all failures are non-fatal, but may affect testing accuracy)
----- [OK] Unlocking diagnostic VM options
Burning up to figure out the exact CPU count....... done!
----- [OK] Trimming down the default VM heap size to 1/8-th of max RAM
----- [OK] Trimming down the number of compiler threads
----- [OK] Trimming down the number of parallel GC threads
----- [OK] Trimming down the number of concurrent GC threads
----- [OK] Trimming down the number of G1 concurrent refinement GC threads
----- [OK] Testing #Contended works on all results and infra objects
----- [OK] Unlocking Whitebox API for online de-optimization
----- [OK] Testing allocation profiling
----- [FAILED] Trying Thread.onSpinWait
Exception in thread "main" java.lang.NoSuchMethodError: java.lang.Thread.onSpinWait()V
at org.openjdk.jcstress.vm.ThreadSpinWaitTestMain.main(ThreadSpinWaitTestMain.java:30)
Hardware threads in use/available: 8/8, no yielding.
Test preset mode: "default"
Writing the test results to "jcstress-results-2019-02-05-22-08-52.bin.gz"
Parsing results to "results/"
Running each test matching ".*" for 1 forks, 5 iterations, 1000 ms each
Each JVM would execute at most 5 tests in the row.
Solo stride size will be autobalanced within [10, 10000] elements, but taking no more than 100 Mb.
Exception in thread "main" java.lang.NullPointerException
at java.io.Reader.<init>(Reader.java:78)
at java.io.InputStreamReader.<init>(InputStreamReader.java:72)
at org.openjdk.jcstress.infra.runners.TestList.getTests(TestList.java:53)
at org.openjdk.jcstress.infra.runners.TestList.tests(TestList.java:105)
at org.openjdk.jcstress.JCStress.getTests(JCStress.java:139)
at org.openjdk.jcstress.JCStress.run(JCStress.java:67)
at org.openjdk.jcstress.Main.main(Main.java:60)
Command which I use to run tests:
java -cp jars/jcstress-core-0.5.jar:jars/jopt-simple-4.6.jar org.openjdk.jcstress.Main
When you try the newest version like JDK 16/17, it should work fine.
You did not say which version of Java you used. But the same thing happens for me with a Windows JDK-8 build from Oracle. JDK-12 seems to be fine, though. Also, you could try one of these: https://builds.shipilev.net/.
I have a Proton CEP instance deployed on my own server with 2 CPUs and 4GB RAM.
After leaving it working overnight, CPU usage increases heavily, up to 100% of each core. The command being executed is:
java -Djava.security.egd=file:/dev/./urandom -Djava.awt.headless=true -Xmx512m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat/temp -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start
Looking at the logs, I also see:
Feb 17, 2016 10:00:00 AM com.ibm.hrl.proton.server.executorServices.SimpleThreadFactory$ProtonExceptionHandler uncaughtException
SEVERE: Uncaught exception in thread: Thread[31516,5,main],exception: Java heap space
Feb 17, 2016 10:02:31 AM com.ibm.hrl.proton.server.executorServices.SimpleThreadFactory$ProtonExceptionHandler uncaughtException
SEVERE: Uncaught exception in thread: Thread[31643,5,main],exception: Java heap space
Althought from htop it seems that up to 2 GB of RAM are still free.
Is this normal?
The same server is also running Orion, but that one is not experiencing issues.
The problem was that due to a bug in our code, we were sending ever larger requests with data to Orion which forwarded them to Proton. Eventually the requests grew from 100B to over 50MB, causing Proton to stall as it was unable to process all the data in time.