问题描述
我们有大约 20 个 linux 刀片池.有些运行 Suse，有些运行 Redhat.ALL 共享 NAS 空间，其中包含以下 3 个文件夹:
We have a pool of aproximately 20 linux blades. Some are running Suse, some are running Redhat. ALL share NAS space which contains the following 3 folders:
- /NAS/app/java - 指向 Java JDK 安装的符号链接.当前版本 1.5.0_10
- /NAS/app/lib - 指向我们应用程序版本的符号链接.
- /NAS/data - 写入输出的目录
我们所有的机器都有 2 个处理器(超线程)，4gb 物理内存和 4gb 交换空间.我们将每台机器在给定时间可以处理的作业"数量限制为 6 个(这个数字可能需要更改，但这不会影响当前问题，因此请暂时忽略).
All our machines have 2 processors (hyperthreaded) with 4gb of physical memory and 4gb of swap space. We limit the number of 'jobs' each machine can process at a given time to 6 (this number likely needs to change, but that does not enter into the current problem so please ignore it for the time being).
我们的一些作业将最大堆大小设置为 512mb，而其他一些作业将最大堆大小设置为 2048mb.同样，我们意识到如果 6 个作业在同一台机器上启动并且堆大小设置为 2048，我们可以检查可用内存，但据我们所知，这还没有发生.
Some of our jobs set a Max Heap size of 512mb, some others reserve a Max Heap size of 2048mb. Again, we realize we could go over our available memory if 6 jobs started on the same machine with the heap size set to 2048, but to our knowledge this has not yet occurred.
有时，作业会立即失败并显示以下消息:
Once and a while a Job will fail immediately with the following message:
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
我们过去常常把这归结为在同一台机器上同时运行太多作业.这个问题很少发生(可能一个月一次)，我们只需重新启动它，一切都会好起来的.
We used to chalk this up to too many jobs running at the same time on the same machine. The problem happened infrequently enough (MAYBE once a month) that we'd just restart it and everything would be fine.
问题最近变得更糟了.我们所有要求最大堆大小为 2048m 的作业几乎每次都会立即失败，并且需要多次重启才能完成.
The problem has recently gotten much worse. All of our jobs which request a max heap size of 2048m fail immediately almost every time and need to get restarted several times before completing.
我们已经在单独的机器上尝试手动执行它们，结果相同.
We've gone out to individual machines and tried executing them manually with the same result.
事实证明，问题只存在于我们的 SuSE 盒子上.它发生得更频繁的原因是因为我们一直在添加更多的机器，而新的机器是 SuSE.
It turns out that the problem only exists for our SuSE boxes. The reason it has been happening more frequently is becuase we've been adding more machines, and the new ones are SuSE.
SuSE 盒子上的cat/proc/version"给我们:
'cat /proc/version' on the SuSE boxes give us:
Linux version 2.6.5-7.244-bigsmp (geeko@buildhost) (gcc version 3.3.3 (SuSE Linux)) #1 SMP Mon Dec 12 18:32:25 UTC 2005
RedHat 盒子上的cat/proc/version"给我们:
'cat /proc/version' on the RedHat boxes give us:
Linux version 2.4.21-32.0.1.ELsmp ([email protected]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-52)) #1 SMP Tue May 17 17:52:23 EDT 2005
'uname -a' 在两种类型的机器上都为我们提供了以下信息:
'uname -a' gives us the following on BOTH types of machines:
UTC 2005 i686 i686 i386 GNU/Linux
机器上没有正在运行的作业，也没有其他进程正在使用大量内存.当前运行的所有进程可能总共使用 100mb.
No jobs are running on the machine, and no other processes are utilizing much memory. All of the processes currently running might be using 100mb total.
'top' 当前显示以下内容:
'top' currently shows the following:
Mem: 4146528k total, 3536360k used, 610168k free, 132136k buffers
Swap: 4194288k total, 0k used, 4194288k free, 3283908k cached
'vmstat' 当前显示以下内容:
'vmstat' currently shows the following:
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 610292 132136 3283908 0 0 0 2 26 15 0 0 100 0
如果我们使用以下命令行(最大堆为 1850mb)启动一个工作，它开始正常:
If we kick off a job with the following command line (Max Heap of 1850mb) it starts fine:
java/bin/java -Xmx1850M -cp helloworld.jar HelloWorld
Hello World
如果我们将最大堆大小提高到 1875mb，它就会失败:
If we bump up the max heap size to 1875mb it fails:
java/bin/java -Xmx1875M -cp helloworld.jar HelloWorld
Error occurred during initialization of VM
Could not reserve enough space for object heap
Could not create the Java virtual machine.
很明显，当前正在使用的内存用于缓冲/缓存，这就是为什么显示为空闲"的内存如此之少.不清楚的是为什么会有一个神奇的 1850mb 行，其中任何更高的行都意味着 Java 无法启动.
It's quite clear that the memory currently being used is for Buffering/Caching and that's why so little is being displayed as 'free'. What isn't clear is why there is a magical 1850mb line where anything higher means Java can't start.
任何解释将不胜感激.
推荐答案
您使用的是 32 位操作系统，因此您将看到总大小受到限制.其他答案更详细地介绍了这一点，因此我将避免重复他们的信息.
You're using a 32-bit OS, so you're going to be seeing limits on the total size due to that. Other answers have covered this in more detail, so I'll avoid repeating their information.
我最近在我们的服务器上注意到的一个行为是使用 -Xmx 指定最大堆大小而不使用 -Xms 指定最小堆大小会导致 Java服务器 VM 立即尝试分配最大堆大小所需的所有内存.当然，如果应用程序达到该堆大小，这就是您需要的内存量.但很有可能，您的应用开始时使用的堆相对较小，并且 稍后可能需要更大的堆.此外，指定最小堆大小将使您的应用从较小的堆开始，然后逐渐增大该堆.
A behaviour that I noticed with our servers recently is that specifying a maximum heap size with -Xmx while not specifying a minimum heap size with -Xms would lead to Java's server VM immediately attempting to allocate all of the memory needed for the maximum heap size. And sure, if the app gets up to that heap size, that's the amount of memory that you'll need. But the chances are, your apps will be starting out with comparitively small heaps and may require the larger heap at some later point. Additionally specifying the minimum heap size will let you start your app start with a smaller heap and gradually grow that heap.
所有这些都不会帮助您增加最大堆大小，但我认为它可能会有所帮助，所以...
All of this isn't going to help you increase your maximum heap size, but I figured it might help, so...
这篇关于Java 拒绝启动 - 无法为对象堆保留足够的空间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！