I switched to the Azul JVM in order to use a native ARM JVM and Solr was no longer able to start up. I started seeing a new error in the log:
The stack size specified is too small, Specify at least 384k
If I switch back to the Oracle jvm I do not get this error.
Requirements for stack size appears to be different between ARM and x86 JVMs.
The relevant lines setting the default in bin/solr is:
# Pick default for Java thread stack size, and then add to SOLR_OPTS
if [ -z ${SOLR_JAVA_STACK_SIZE+x} ]; then
SOLR_JAVA_STACK_SIZE='-Xss256k'
fi
SOLR_OPTS+=($SOLR_JAVA_STACK_SIZE)
The default is too small for the ARM JVM to start up. To increase the stack size add the following line to bin/solr.in.cmd
SOLR_JAVA_STACK_SIZE='-Xss512k'
I faced the same error when trying to start Solr for my Rails app.
After a lot of digging, I fixed it by adding the following line to my .zshrc file.
export _JAVA_OPTIONS='-Xss512k'
My use case:
macOS Monterey (M1 2020)
openjdk version "1.8.0_332"
OpenJDK Runtime Environment (Zulu 8.62.0.19-CA-macos-aarch64) (build 1.8.0_332-b09)
OpenJDK 64-Bit Server VM (Zulu 8.62.0.19-CA-macos-aarch64) (build 25.332-b09, mixed mode)
Related
I ran this command which I found in this blog.
docker run -m 1GB openjdk:10 java \
-XX:+UseContainerSupport \
-XX:MinRAMPercentage=50 \
-XX:MaxRAMPercentage=80 \
-XshowSettings:vm \
-version
My output is this.
VM settings:
Max. Heap Size (Estimated): 3.86G
Using VM: OpenJDK 64-Bit Server VM
openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Debian-2)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Debian-2, mixed mode)
I am little bit confused now is that , when I limit the memory to 1G, why does Java see 3.86G or What needs to be done to make java see container memory limits ?
Note: I am on MAC. docker creates container inside the VM. So not sure if it matters.
When using Java in containers, one needs to be mindful of to what degree the JVM is aware of the resource limits set for the container it runs in. With Java version 10 (released in 2018) the JVM was first enabled to figure out whether it is running in a container, and if yes, how much memory was allocated to the container. Back then, CGroups V1 was used by the Linux Kernel to curtail the memory available to containers.
In the mean time, CGroups V2 (conceived in 2016) is gaining traction and is increasingly becoming the default for new Linux releases (e.g. Ubuntu and Flatcar Linux made it default in 2021). This means, once again a Java update is required to support CGroups V2 for correct handling of JVM resource limits and Heap configuration, which for OpenJDK came with Java version 15.
I'm currently setting up two Geoservers running on two separate Linux machines. One of the Geoservers is running version 2.20.2. and the other one is version 2.19.5.
I'm trying to install Native Jai and Native JAI ImageIO in order to increase the image handling performance.
Both machines are running Ubuntu 20.04.4 LTS.
java -version
openjdk version "11.0.14" 2022-01-18
OpenJDK Runtime Environment (build 11.0.14+9-Ubuntu-0ubuntu2.20.04)
OpenJDK 64-Bit Server VM (build 11.0.14+9-Ubuntu-0ubuntu2.20.04, mixed mode, sharing)
So far I've followed these instructions: https://download.java.net/media/jai/builds/release/1_1_3/INSTALL.html
Specifically this part: The instructions I followed
It's still not working.
echo $JAIHOME
/var/lib/JAI/jai-1_1_3/lib
echo $CLASSPATH
/var/lib/JAI/jai-1_1_3/lib/jai_core.jar:/var/lib/JAI/jai-1_1_3/lib/jai_codec.jar:/var/lib/JAI/jai-1_1_3/lib/mlibwrapper_jai.jar
echo $LD_LIBRARY_PATH
.:/var/lib/JAI/jai-1_1_3/lib:/var/lib/JAI/jai-1_1_3/lib/jai_core.jar:/var/lib/JAI/jai-1_1_3/lib/jai_codec.jar:/var/lib/JAI/jai-1_1_3/lib/mlibwrapper_jai.jar
This is the Geoserver status page in case there is any relevant information: Geoserver status
Any help would be greatly appreciated.
I'm not sure why that section still appears in the manual - it is no longer needed or recommended, but is clearly marked as outdated.
I am trying to profile a remote JVM with VisualVM 1.4. I am running macOS High Sierra 10.13.6 locally, with the following OpenJDK version:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_181-b13)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.181-b13, mixed mode)
The server runs Debian Stretch with the following OpenJDK:
java -version
openjdk version "1.8.0_181"
OpenJDK Runtime Environment (build 1.8.0_181-8u181-b13-2~deb9u1-b13)
OpenJDK 64-Bit Server VM (build 25.181-b13, mixed mode)
When I monitor a JVM process locally, I see all these tabs and the profiling works just fine.
However, if I do that remotely, I see something like this:
Note the CPU window that says "Not supported for this JVM" and the reduced tabs, not including "Profiler". However, as you can see, I do see some data.
I am connecting via jstatd. On the server, following this article, I am running
jstatd -J-Djava.security.policy=/home/brandwatch/jstatd.all.policy -J-Djava.rmi.server.hostname=10.2.156.160 -Djava.rmi.server.logCalltrue
Answers like this indicate that this might be due to different JVM versions, however, mine appear to be the same, despite one of them running on MacOS and one of them on Debian.
Missing CPU usage information has nothing to do with with different JDK versions. You don't see CPU usage data because jvmstat (exported via jstatd) does not provide such information. If you want to see CPU usage, you need to use JMX connection. JMX will also allow you to do CPU and Memory sampling. Profiling is supported for local applications only.
Because, as Tomas Hurka's answer correctly indicates, remote profiling does not work with VisualVM, I have used a little hack to still make it work: I have installed VisualVM on the remote server and accessed it via X-forwarding. That way, VisualVM can access the process locally an thus profile it.
ssh into the server with the -X flag
ssh -C -X <user>#<host>
download [VisualVM 1.4][8]
wget https://github.com/visualvm/visualvm.src/releases/download/1.4/visualvm_14.zip
unzip the archive
unzip visualvm_14.zip
run VisualVM
./visualvm_14/bin/visualvm
After a few seconds you should see a VisualVM window pop up. It's not very fast (just because x-forwarding is not), but for my use case it was alright.
Another way of achieving this might be using VNC, but I haven't tried that. The downside would be that you have to install all the desktop packages, which one might not want on a server.
I need to set
ANT_OPTS=-Xms1024m -Xmx6144m -XX:PermSize=1024m -XX:MaxPermSize=1024m
JAVA_OPTS=-Xms1024m -Xmx6144m -XX:PermSize=1024m -XX:MaxPermSize=1024m
I have a system with 8gb(recently upgraded from 4 gb)
But once i set the ant opts to above said value I am not able to run any of my ant targets and I get the following error
[ERROR] Argument error: -Xmx6144m
[ERROR] Specified maximum heap size (6144 MB) is larger than the address space on this platform (4 GB).
[WARN ] -XX:PermSize=1024m is not a valid VM option. Ignoring
[WARN ] -XX:MaxPermSize=1024m is not a valid VM option. Ignoring
Could not create the Java virtual machine.
This indicates the Java that I have on my system
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Oracle JRockit(R) (build R28.1.0-123-138454-1.6.0_20-20101014-1351-windows-x86_64, compiled mode)
and I am running a Windows 7 on Intel Core 2 Duo 3Ghz processor and 8GB RAM.
PS: I did Google for the error and it was one of my first such occurrences where I did not get any links pointing to the specific solution.
As discussed in the comments:
It would seem that your ANT installation is using a 32-bit JVM. While a 64-bi JVM is in your PATH ANT doesn't obey the JVM in your PATH, it first looks at JAVA_HOME. You can verify this by running $JAVA_HOME/bin/java -version.
You can update your environment to set JAVA_HOME to the 64-bit version or change the ANT script to always use a specific version of Java.
The error message appears to be suggesting the platform is 32-bit. I imagine you can't actually use 4 GB.
I would try installing the 64-bit version of Java and using that.
For the HotSpot JVM I would expect to see
$ java -mx30g -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
I'm using Jboss and I added -XX:+HeapDumpOnCtrlBreak option to JAVA_OPTS.
But I got the error when starting Jboss:
Unrecognized VM option '+HeapDumpOnCtrlBreak'
Could not create the Java virtual machine.
I've searched on the net and it seems JDK 6 doesn't support this option so I changed to jdk1.5.0_09 but still got this error.
Does anyone know what's wrong?
the option doesn't work even on JDK 1.7 update 25:
>>java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b16)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
>>java -XX:+HeapDumpOnCtrlBreak
Unrecognized VM option 'HeapDumpOnCtrlBreak'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Alright, seems that I need Java SE release 5.0 update 14 or above.
Changes in 1.4.2_21
http://www.oracle.com/technetwork/java/javase/documentation/overview-142120.html
6321286 java serviceability Add -dump option to jmap so that a cooperative heap dump can be obtained from a running VM.
6454676 java serviceability Need -XX:+HeapDumpOnCtrlBreak to trigger heap dump on ctrl-break or ctrl-\
6608975 java serviceability HeapDumpPath option is ignored for dumps written by HeapDumpOnCtrlBreak functionality
Upgrade to Jdk 1.4.2_21+ can help us support this heap dump generation functionality
-XX:+HeapDumpOnCtrlBreak in HotSpot JVM (by Sun/Oracle) is present in 1.4.2_12 or higher and 1.5.0_14 or higher. For JVMs 1.6, 1.7, 1.8 this option is no more present, but you can use the "jmap" tool (jmap.exe -dump:format=b,file=HeapDump.hprof)
In HP-UX JVM the option is present in versions 1.4.2_11 or higher, and 1.5.0_05 and higher. And in all later versions (1.6, 1.7).
For more infos see A searchable collection of JVM options - HeapDumpOnCtrlBreak