Jenkins is failing to start a 32
I'm running Jenkins 1.557. I have a job that I need to be built with a 32-bit version of JDK 1.6_u45. I have that version properly configured in my job's JDK setting. However, when I attempt to run the job, I get the following error.
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
If I switch the job's JDK setting to a 64-bit version, the JVM is able to be created and it runs as normal. The server has 8GB of RAM available, and I've even attempted to pass in a string parameters of JAVA_OPTS=-Xms512m -Xmx1024m & ANT_OPTS=-Xms512m -Xmx1024m to the build, but to no avail.
Please note this is not a duplicate of Could not reserve enough space for object heap. If I attempt to build the project at a regular command line (Windows environment variable JAVA_HOME pointing to the same 32-bit JDK installation as the Jenkins attempt), the project builds. This is seemingly a Jenkins specific issue.
My guess is somewhere in Jenkins (or in some hidden Jenkins config file) the JVM heap size is being set too large for the 32-bit JVM, but I can't seem to pinpoint where that is being set. I've checked the jenkins.xml in JENKINS_HOME but the heap size is not being set in the arguments tag.
Answer
Try a lower max heap (-Xmx) value, such as -Xmx900m or -Xmx800m and see if this solves the problem. From my experience, Jenkins honors your ANT_OPTS environment variable and does not mess with it. I use Jenkins Freestyle Jobs that launch Ant personally and I've always set ANT_OPTS, MAVEN_OPTS, ... separate from Jenkins and it has never changed anything. Make
Better yet, start with a much lower value like -Xmx512m (I would use ANT_OPTS, which Ant uses for this and not bother with JAVA_OPTS). If it still fails to initialize, OK, then maybe I'll entertain that Jenkins is doing something. If not, there's your answer.
At the root, I believe this is the same problem as the duplicate question you linked, it just reproduces in more limited circumstances. More details below.
Background
Just yesterday, on a coworker's machine I saw -Xmx1024m fail in a standard command window with the same message with 32-bit Java. Just because it works in one situation does not mean it will always work.
On Windows, 2GB max address space per 32-bit process severely limits the maximum heap size you can set in Java since Java requires that the entire object heap be allocated in one contiguous block. Especially in modern versions of Windows that use ASLR (Address Space Layout Randomization), you simply can't be guaranteed large heap sizes for 32-bit processes...even 1024m can sometimes be too large since in Java the heap must be contiguous. Picture a horizontal line from 0 to 2GB, and then a [1GB] chunk taking up 50% of the width. Now insert 50 random DLLs into that 2GB horizontal line in random locations...now try to fit your [1GB] chunk without hitting a dot.
Not exact, here's my poor man's diagram of the address space:
0 [________________________________________] 2GB
_ is unallocated, available, | is occupied
Now with DLLs:
0 [__|_______|___________________|___|_____] 2GB
You need to fit this (including edges) into that address space:
[__________________]
Maybe it barely squeeks in...now let's add one more blip
0 [__|_______|_____________|_____|___|_____] 2GB
[__________________]
Suddenly it won't fit.
It's possible there is an extra DLL being loaded by Jenkins that is fragmenting your address space just slightly more so that 1024m fails under Jenkins but not in a standalone window. Since your goal is to run it under Jenkins, I don't see a clear solution to that other than to reduce your max heap size since your goal is to run a 32-bit build. In the Windows XP days, it was common to get -Xmx1300m or so to work, but apparently even -Xmx1024m is a stretch on Windows 7 and Windows 8 (in some cases, anyway). It really seems like the most likely case is...you're trying to set the heap too big for 32-bit.
Verification
If this really isn't the problem, or if you don't believe me, you can verify what Java memory settings your 64-bit version of the build is actually using (namely because it has to actually start to see the settings while it's running). Since your other build is failing to even start, I'm not sure you can use this method there. Whether Jenkins is doing something or not, whether you tell your job to use a 32-bit JDK or 64-bit JDK, if it's reading ANT_OPTS it should be the getting the same end result -Xmx value from that environment variable for both builds (the one that works (64-bit), and the one that fails). You can use a utility included with the JDK to do this called jconsole. From the bin directory of your JDK installation, run 'jconsole'. Or, if you have %JAVA_HOME%bin in your PATH, you should be able to directly launch jconsole.
This will start a graphical client allowing you to select from any Process IDs (PIDs) that have a JVM running in them, this list should be pretty short in most cases. Select your Ant process and connect to it. Switch to the VM Information tab, and you will see the heap settings and other VM arguments that the JVM is using.
You will see a "VM Arguments" section, which should include your -Xms and -Xmx settings, but also "Maximum Heap Size", which will probably display in kilobytes.
Bonus knowledge, but not directly relevant since you've stated Java 6. If this were Java 7 or later, you could use:
jcmd
to obtain the PID, then:
jcmd <PID> VM.arguments
to see the VM arguments for the Java process with the PID you specified. jcmd being another utility that comes with the JDK. This, for me at least, displays the raw bytes value so you'll need to translate in your head. (it won't show -Xmx1024m it will show -XX:MaxHeapSize=1073741824)
链接地址: http://www.djcxy.com/p/82922.html下一篇: 詹金斯未能开始32岁