什么是SuSE Linux的最大Java堆空间
这个问题与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
JVM内存限制与可用的最大空闲连续块相关，而不是可用内存量。 该限制从约1.4 GB到略高于2.0 GB不等，并取决于操作系统在内存中放置各种内容的位置。 我不知道Redhat或Suse将内容加载到内存中的细节，但可能是因为suse将某些库映射到RAM中间的地址，Redhat可能会在最后映射它（推测）。
请记住，您在java中的实际内存使用量超过了您为Xmx指定的内存使用量。 其他内存设置也会影响堆的大小（如permgen）。 所以也可能是Suse上的perm空间比redhat有更大的默认空间。
另外，根据应用程序的内存分配配置文件，您可能会获得较小的堆大小和不同的垃圾收集选项。 这里有一些细节（http://java.sun.com/performance/reference/whitepapers/tuning.html）和其他地方。 例如，如果你分配了很多小的临时块，你会需要不同的GC设置，如果你有很多长寿命的对象。
关于链接的问题，为什么不使用Redhat？ 这可能是一个简单的解决方案，但我保证它会比解决Java调优和操作系统内存管理这个神秘的世界更快地解决您的问题：P
首先，当你有这么多的地址空间压力时，你疯狂地运行32位操作系统。 迁移到64位Linux上的64位JVM。 您已经浪费了多少时间来尝试诊断您从一开始就必须怀疑的问题，将会消除64位系统的较大地址空间？
其次，众所周知，在所有Linux厂商中，红帽拥有最多的内核工程师，并对其RHEL产品中的内核进行了一些严格的调整。 这些通常包括像您这样的大型工作负载的修补程序（对于32位系统来说这是一个很大的工作负载，在64位上并没有什么特别的）。 所以最终的原因是RHEL的其他客户和你一样疯狂，你也从他们为支持这些客户所做的工作中受益。
最后，因为我怀疑你会坚持尝试在32位SuSE上找到一种方法来做到这一点，我将指出Linux在32位x86上提供了各种地址空间权衡，并且有可能（但不确定）您的SuSE系统选择了不同的权衡。 如果你可以调出正在运行的内核的配置（通常在/ boot / config ....），那么你可以比较像HIGHMEM这样的设置。
直到几年前的传统选项是2：2分割，即用户空间限于2GiB的地址空间，这是一个简单的程序解决方案，它具有良好的效率，但在这种情况下显然你不能拥有你所需的堆，因为它将不会为程序文本，堆栈等留出空间。最近趋势是以3：1（类似于Windows / 3GB交换机）的方式扩展用户空间地址空间，代价是将操作系统内核本身占用较少的空间造成自己的问题。 这可能会奏效，但它会非常拥挤，所以如果它不适合你的工作，我也不会感到惊讶。 最后，较新的Linux内核还提供一个选项，您可以获得4GiB 32位用户空间，这足以使您的作业可靠运行，并且性能成本很高，因为显然用户空间和内核地址不能共存。
要试试这个，你需要一个新的内核。 您可能只能安装由SuSE提供的一个（请参阅他们是否提供其他人选择，例如“PAE”选项），或者您可能需要编译自己的，在这种情况下，它可能会使支持合同失效。
但是，真的，你应该选择选项1，切换到64位JVM并放脚。
链接地址: http://www.djcxy.com/p/82887.html