java - Jenkins无法启动工作的32位JVM

Question

我正在运行詹金斯1.557。我有一份工作需要使用32位版本的JDK 1.6_u45构建。我在工作的JDK设置中正确配置了该版本。但是，当我尝试运行该作业时，出现以下错误。

Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.

如果我将作业的JDK设置切换为64位版本，则可以创建JVM，并且它可以正常运行。该服务器有8GB的可用内存，我什至尝试将JAVA_OPTS = -Xms512m -Xmx1024m和ANT_OPTS = -Xms512m -Xmx1024m的字符串参数传递给该版本，但无济于事。

请注意，这不是 Could not reserve enough space for object heap的副本。如果我尝试在常规命令行上构建项目(Windows环境变量JAVA_HOME指向与Jenkins尝试相同的32位JDK安装)，则将构建项目。这似乎是詹金斯特有的问题。

我的猜测是在Jenkins(或某些隐藏的Jenkins配置文件)中，对于32位JVM，JVM堆大小设置得太大，但我似乎无法查明设置的位置。我检查了JENKINS_HOME中的jenkins.xml，但未在arguments标记中设置堆大小。

Answer 1

回答

尝试使用较低的最大堆(-Xmx)值，例如-Xmx900m或-Xmx800m，看看是否可以解决问题。
根据我的经验，Jenkins尊重您的ANT_OPTS环境变量，并且不会对此感到困惑。我使用Jenkins Freestyle Jobs亲自启动Ant，并且我总是将ANT_OPTS，MAVEN_OPTS，...与Jenkins分开设置，并且从未更改过任何内容。使

更好的是，从一个较低的值开始，例如-Xmx512m(我将使用ANT_OPTS，Ant为此使用该值，而不必理会JAVA_OPTS)。如果仍然无法初始化，可以，那么我可能会觉得詹金斯正在做某事。如果没有，那是你的答案。

从根本上讲，我认为这与您链接的重复问题是相同的问题，只是在更有限的情况下才会出现。下面有更多详细信息。

背景

就在昨天，在同事的机器上，我看到-Xmx1024m在标准命令窗口中失败，并带有与32位Java相同的消息。仅仅因为它在一种情况下有效并不意味着它将一直有效。

在Windows上，每32位进程2GB的最大地址空间严重限制了您在Java中可以设置的最大堆大小，因为Java要求将整个对象堆分配在一个连续的块中。特别是在使用ASLR(地址空间布局随机化)的现代Windows版本中，您根本无法保证32位进程的大堆大小...甚至1024m有时也可能太大，因为在Java中堆必须是连续的。画一条从0到2GB的水平线，然后画一个[1GB]的块占用宽度的50％。现在，在随机位置的2GB水平线上插入50个随机DLL ...现在尝试装入您的[1GB]块而不碰到一个点。

不确切，这是我可怜的人的地址空间图:

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. 

Jenkins可能加载了一个额外的DLL，这会使您的地址空间碎片化得更多，从而使1024m在Jenkins下无法正常运行，但在独立窗口中无法运行。由于您的目标是在Jenkins下运行它，因此，除了减少最大堆大小之外，我看不到其他解决方案，因为您的目标是运行32位构建。在Windows XP时代，使-Xmx1300m左右正常工作是很常见的，但显然-Xmx1024m在Windows 7和Windows 8上也是一个延伸(在某些情况下，无论如何)。似乎最有可能的情况是...您正试图将堆设置为对于32位太大。

验证

如果这确实不是问题，或者您不相信我，则可以验证您的64位版本的构建实际使用了哪些Java内存设置(即因为它必须在构建时实际开始查看设置)正在运行)。由于您的其他构建版本甚至无法启动，因此我不确定您是否可以在此处使用此方法。不管Jenkins是否正在做某件事，是否告诉您的工作使用32位JDK还是64位JDK，如果它正在读取ANT_OPTS，则应该从该环境变量为两个版本获得相同的最终结果-Xmx值(一种有效(64位)，另一种无效)。您可以使用JDK附带的实用程序来执行此操作，称为jconsole。在您的JDK安装目录的bin目录中，运行“jconsole”。或者，如果您的PATH中有％JAVA_HOME％\ bin，则应该可以直接启动jconsole。

这将启动一个图形客户端，允许您从其中运行JVM的任何进程ID(PID)中进行选择，在大多数情况下，此列表应该很短。选择您的Ant进程并连接到它。切换到“VM信息”选项卡，您将看到JVM使用的堆设置和其他VM参数。

您将看到“VM Arguments”部分，其中应包括-Xms和-Xmx设置，以及“Maximum Heap Size”(可能以千字节为单位)。

丰富的知识，但是自从您说过Java 6以来就没有直接的关系。如果是Java 7或更高版本，则可以使用:

jcmd

获取PID，然后:

jcmd <PID> VM.arguments

查看具有指定PID的Java进程的VM参数。 jcmd being another utility that comes with the JDK。至少对我来说，这显示了原始字节值，因此您需要在头脑中进行翻译。 (它不会显示-Xmx1024m，它会显示-XX:MaxHeapSize = 1073741824)