Question

我们有生产Tomcat（6.0.18）服务器，它使用以下设置运行：

-server -Xms7000M -Xmx7000M -Xss128k -XX:+UseFastAccessorMethods 
-XX:+HeapDumpOnOutOfMemoryError -Dcom.sun.management.jmxremote.port=7009 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false -verbose:gc -XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/opt/apache-tomcat-6.0.18/conf/logging.properties 
-agentlib:jdwp=transport=dt_socket,address=8000,server=y,suspend=n 
-Djava.endorsed.dirs=/opt/apache-tomcat-6.0.18/endorsed 
-classpath :/opt/apache-tomcat-6.0.18/bin/bootstrap.jar

java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

经过一段时间的工作，我们得到（通过JConsole）以下内存消耗：

Current heap size: 3 034 233 kbytes
Maximum heap size: 6 504 832 kbytes
Committed memory:  6 504 832 kbytes
Pending finalization: 0 objects
Garbage collector: Name = 'PS MarkSweep', Collections = 128, Total time spent = 16 minutes
Garbage collector: Name = 'PS Scavenge', Collections = 1 791, Total time spent = 17 minutes

Operating System: Linux 2.6.26-2-amd64
Architecture: amd64
Number of processors: 2

Committed virtual memory: 9 148 856 kbytes
Total physical memory:  8 199 684 kbytes
Free physical memory:     48 060 kbytes
Total swap space: 19 800 072 kbytes
Free swap space: 15 910 212 kbytes

问题是为什么我们有很多提交的虚拟内存？请注意，最大堆大小约为7Gb（正如预期的那样，Xmx = 7G）。

顶部显示以下内容：

31413 root  18  -2 8970m 7.1g  39m S   90 90.3 351:17.87 java

为什么JVM需要额外的2Gb！虚拟内存？我可以像JRockit http://blogs.oracle.com/jrockit/2009/02/why_is_my_jvm_process_larger_t.html中那样获得非堆内存分配吗？

编辑1：烫发是36M。

Answer 1

-Xms7000M -Xmx7000M

对我来说，对JVM说“将7gb分配为初始堆大小，最大为7gb”。

因此，对于操作系统来说，进程总是7gb，因为这是JVM通过Xms标志所要求的。它实际上在JVM内部使用的是报告为几百mb的堆大小。通常，在防止由于过多的垃圾收集导致速度减慢时设置高Xms。当JVM在使用中达到（JVM定义的）内存百分比时，它将进行快速垃圾收集。如果这不能释放内存，那么它将尝试一个详细的集合。最后，如果此操作失败并且尚未达到Xmx定义的最大内存，那么它将要求操作系统获得更多内存。所有这些都需要时间，并且可以在生产服务器上真正注意到 - 提前执行此操作可以避免这种情况发生。

Answer 2

你可能想尝试将JConsole连接到你的JVM并查看内存分配...也许你的Perm空间正在增加2GB ...堆只是你的VM需要活着的一部分...

Answer 3

似乎这个问题是由JVM发生的大量页面错误引起的。很可能当Sun的JVM遇到大量页面错误时，它开始分配额外的虚拟内存（仍然不知道为什么），这可能反过来增加IO压力等等。因此，我们在完整的GC上获得了非常高的虚拟内存消耗和周期性挂起（最多30分钟）。

有三件事帮助我们在生产中获得稳定的工作：

降低Linux内核交换的趋势（有关说明，请参见此处What Is the Linux Kernel Parameter vm.swappiness?）有很多帮助。我们在运行大量后台JVM任务的所有Linux服务器上都有vm.swappiness=20。
减小最大堆大小值（-Xmx）以防止对OS本身造成过大压力。我们现在在12GB机器上有9GB的价值。
最后但非常重要的 - 代码分析和内存分配会阻碍优化，以尽可能消除分配突发。

这就是全部。现在服务器运行良好。

Answer 4

我不熟悉jconsole，但你确定JVM正在使用额外的2Gb吗？在我看来，它是操作系统或其他进程，总计高达9Gb。

此外，使用比-Xmx param明显更多的虚拟内存的JVM的常见解释是，您有内存映射文件（MappedByteBuffer）或使用使用MappedByteBuffer的库。

Sun JVM承诺虚拟内存消耗高

4 个答案: