问64位JVM限制在300 of内存？

EN

我可以想到几个可能的解释：

• 您系统上的其他应用程序使用的内存太多，目前没有300‘t的内存可用。
• 每个进程的内存大小可能存在资源限制。您可以使用ulimit进行检查。(请注意，根据这只虫子，如果每个进程资源限制停止JVM分配堆区域，您将得到错误消息。)
• 这也可能是一个“过度提交”的问题；例如，如果您的应用程序在虚拟环境中运行，并且整个系统无法满足需求，因为来自其他虚拟化者的竞争太多了。

提出的其他几个想法(海事组织)不太可能：

• 改变JRE不太可能产生任何影响。我从未听说或见过特定64位JVM中的任意内存限制。
• 这不太可能是因为没有足够的连续记忆。当然，不需要连续的物理内存。唯一的可能性可能是交换设备上的相邻空间，但我不记得这对于典型的Linux OSes来说是个问题。

有人能提出解决方案/解决办法吗？

• 检查一下ulimit。
• 编写一个小型C程序，尝试malloc大量内存，并查看在失败之前可以分配多少内存。
• 请系统(或系统管理程序)管理员提供帮助。

(编辑，请参阅关于交换空间的新增部分)

SHMMAX和SHMALL

由于您使用的是CentOS，您可能遇到了类似于描述的SHMMAX和SHMALL内核设置的问题。在该链接下面是一个示例计算，用于获取和设置正确的SHMALL设置。

连续记忆

一些用户已经报告说，没有足够的连续内存可用，其他人说它是不相干的。

我不确定CentOS上的JVM是否需要一个连续的内存块。根据SAS，分段内存可以阻止JVM以很大的Xmx启动或启动Xms内存设置，但互联网上的其他声明称这并不重要。我试图在我的48 of工作站上证明或不证明这一点，但是我成功地启动了JVM，初始和最大设置为40 of。我非常肯定没有这样大小的连续块可用，但是不同操作系统上的JVM的行为可能有所不同，因为每个操作系统的内存管理可能不同(也就是说，Windows通常隐藏单个进程的物理地址)。

查找最大的连续内存块

使用/proc/meminfo查找最大的可用连续内存块，请参见VmAllocChunk下面的值。所有值的这是一个指南和解释。如果您看到的值小于300 If，请尝试一个位于VmAllocChunk值之下的值。

但是，通常这个数字高于物理可用内存(因为它是可用的虚拟内存值)，它可能会给您带来假阳性。这是你可以保留的价值，但一旦你开始使用它，它可能需要交换。因此，您还应该检查MemFree和Inactive值。相反，您也可以查看整个列表，查看哪些值不超过300 at。

其他调优选项，您可以检查64位JVM

我不知道你为什么在300 at的时候遇到内存限制问题。有一段时间，我想你可能已经达到了最大的页数。在默认为4kB的情况下，300 4kB为78,643,200页面。看上去不像是什么著名的神奇数字。例如，如果2^24是最大值，那么16,777,216页面或64 be应该是理论上可分配的最大值。

但是，假设为了证明您需要更大的页面(事实证明，对于大内存Java应用程序的性能而言，这更好)，您应该使用在JBoss上查阅此手册，它解释了如何使用-XX:+UseLargePages并设置kernel.shmmax (同样也有)、vm.nr_hugepages和vm.huge_tlb_shm_group (不确定后者是必需的)。

强调你的系统

其他人也已经提出了这一点。要找出问题在于JVM而不是操作系统，您应该强调这一点。您可以使用的一个工具是斯特雷斯林。在本教程中，您可以找到一些可以使用的选项。您特别感兴趣的是以下命令：

stress --vm 2 --vm-bytes 300G --timeout 30s --verbose

如果该命令失败，或者锁定您的系统，您就会知道操作系统限制了该内存量的使用。如果它成功了，我们应该尝试调整JVM，使它能够使用可用的内存。

编辑Apr6:检查交换空间

具有非常大的内部内存大小的系统很少或根本不使用交换空间，这并不少见。对于许多应用程序来说，这可能不是问题，但是JVM需要交换可用的交换空间大于请求的内存大小。根据这个错误报告，JVM将尝试增加交换空间本身，但是，由于在这个线程建议中的一些答案，JVM可能并不总是能够这样做。

因此:使用cat /proc/swaps # free检查当前可用的交换空间，如果它小于300 it，按照此CentOS手册的说明增加系统的交换空间。

注1:我们可以从布格利波特#4719001中推断，可用交换空间的连续块并不是必需的。但是如果您不确定，删除所有交换空间并重新创建它，它应该删除任何碎片。

注2:我看到了一些类似于这一个报告0MB交换空间和能够运行0MB的帖子。这可能是因为JVM本身增加了交换空间。但是，尝试手动增加交换空间以确定它是否解决了您的问题并不会有什么害处。

过早结论

我意识到以上这些都是对你问题的开箱即用的回答.我希望它能给您提供一些提示，说明您可以尝试如何使JVM正常工作。您也可以尝试其他JVM，如果问题最终证明是您当前使用的JVM的限制，但根据我到目前为止所读到的，不应该对64位JVM设置任何限制。

您在JVM初始化时得到的错误使我相信，问题不在于JVM，而在于操作系统无法遵守300 of内存的预留。

我自己的测试表明，JVM可以访问所有虚拟内存，而不关心可用的物理内存量。如果虚拟内存低于物理内存，这将是奇怪的，但是VmAllocChunk设置应该在这个方向给出提示(它通常要大得多)。

如果您看一看常见问题科 of HotSpot VM，它提到在64位VM上，只有64位的地址位可以使用，因此最大的HotSpot堆大小取决于系统上存在的物理内存和交换空间的数量。

如果您从理论上计算，那么您可以拥有一个18446744073709551616 MB的内存，但是它是有以上限制的。

您必须使用-Xmx命令来定义JVM的最大堆大小，默认情况下在64位JVM上使用64+ 30% = 83.2MB。

我在我的机器上试了一下命令，它看起来很好用。

java -Xmx500g com.test.TestClass

我还试图定义以to为单位的最大堆，但它不起作用。