SuSE Linux的最大Java堆空间是多少

Question

此问题与Java拒绝启动-无法为对象堆预留足够的空间有关 ，应该足够容易找出。 然而; 我的搜索没有产生任何有用的信息。

本质上，我们在具有相同硬件的不同机器上具有2个32位操作系统（RedHat和SuSE）。 两者都使用相同的JVM，并且都执行相同的命令行。 RedHat可以很好地工作，但是SuSE报告没有足够的内存。

我们只需要知道这是否是我们正在使用的SuSE版本的限制或其他原因。

'cat / proc / version'给我们：

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

'uname -a'为我们提供了两种机器的以下信息：

UTC 2005 i686 i686 i386 GNU/Linux

Answer 1

JVM内存限制与可用的最大可用连续块有关，而不与可用内存量有关。 限制从大约1.4 GB到超过2.0 GB不等，具体取决于您的操作系统将各种内容放置在内存中的位置。 我不知道Redhat或Suse将内容加载到内存中的详细信息，但可能是suse将某些库映射到RAM中间的地址，Redhat可能在末尾将其映射（推测）。

请记住，您在Java中的实际内存使用量超过了为Xmx指定的内存使用量。 其他内存设置也会影响堆的大小（例如permgen）。 因此，也可能是Suse上的烫发空间具有比Redhat更大的默认空间。

另外，根据应用程序的内存分配配置文件，您可能会以较小的堆大小和不同的垃圾回收选项而脱身。 这里有一些详细信息（ http://java.sun.com/performance/reference/whitepapers/tuning.html ）和其他地方。 例如，如果您分配了很多小的临时块，那么您将需要不同的GC设置，而不是拥有大量的长期对象。

关于链接的问题，为什么不只使用Redhat？ 那可能是一个简单的解决方案，但是我保证，与深入研究Java调优和OS内存管理的神秘世界相比，它可以更快地解决您的问题：P

Answer 2

首先，当您面临如此大的地址空间压力时，您很疯狂地运行32位操作系统。 迁移到64位Linux上的64位JVM。 您已经浪费了多少时间尝试诊断此问题，而您从一开始就怀疑该问题会随着64位系统的更大地址空间消失？

其次，众所周知，在所有Linux供应商中，Red Hat拥有最多的内核工程师，并对RHEL产品中的内核进行了一些认真的调整。 这些通常包括针对像您这样的大型工作负载的补丁程序（嗯，对于32位系统而言，这是一个很大的工作量，对于64位系统而言，这没什么特别的）。 因此，很有可能最终原因是RHEL会让其他客户做与您相同的疯狂事情，而您从支持这些客户的工作中受益匪浅。

最后，尽管如此，由于我怀疑您将坚持尝试寻找一种在32位SuSE上执行此操作的方法，因此我将指出Linux在32位x86上提供了多种地址空间的折衷方案，并且可能（但不确定）您的SuSE系统只是选择了其他折衷方案。 如果您可以调出正在运行的内核的配置（通常在/ boot / config ....中），则可以比较HIGHMEM之类的设置。

直到几年前，常规选项是2：2拆分，也就是说，用户空间仅限于2GiB地址空间，这是一种易于编程的解决方案，并且效率很高，但在这种情况下，显然您无法拥有所需的堆，因为不会为程序文本，堆栈等留出空间。最近的趋势是3：1（类似于Windows / 3GB开关），这种扩展以牺牲OS内核本身到更少空间的代价为代价，扩展了用户空间地址空间。造成自己的问题。 这可能有用，但是会局促不整，因此如果它对您的工作不起作用，我也不会感到惊讶。 最后，较新的Linux内核还提供了一个选项，您可以在其中获得4GiB 32位用户空间，这可能足以使您的作业可靠地运行，并且性能成本很高，因为显然用户空间和内核地址无法共存。

要尝试此操作，您需要一个新内核。 您也许可以只安装SuSE提供的一个（请查看它们是否提供其他选择，例如“ PAE”选项），或者您可能必须自己编译，在这种情况下，它可能会使您的支持合同无效。

但实际上，您应该只选择选项1，切换到64位JVM，然后站起来。