linux - 为什么在linux & jdk1.6.0_32中JVM不能自动扩充堆内存到配置的Xmx3072m,而且FullGC很频繁

标签 linux garbage-collection jvm

为什么在linux & jdk1.6.0_32中JVM内存不能自动扩展到Xmx3072m?

Tenured 代使用率为 99%,FullGC 的使用频率很高。 java 进程仅使用 1G 内存,如 top 的输出所示。

如果我们将 JVM 参数更改为 -Xms3072m -Xmx3072m,那么它可以正常工作。但是如果我们使用-Xms256m -Xmx3072m,那么问题就出现了,FullGC非常频繁。

这两个参数也是默认的:

MinHeapFreeRatio    40
MaxHeapFreeRatio    70 

环境是:

OS: 

Linux linux-wgvb 2.6.16.60-0.54.5-smp #1 SMP Fri Sep 4 01:28:03 UTC 2009 x86_64 x86_64 x86_64 GNU/Linux 

JDK version: 

java version "1.6.0_32" 
Java(TM) SE Runtime Environment (build 1.6.0_32-b05) 
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode) 

JVM params: 

-Xms256m -Xmx3072m  -XX:+UseParallelOldGC -XX:MaxGCPauseMillis=1000
-XX:ParallelGCThreads=5 -Xrs -XX:PermSize=64m -XX:MaxPermSize=512m
-XX:+HeapDumpOnOutOfMemoryError 

频繁执行FullGC:

@linux> ./jstat -gcutil 18261 1000 500 

   S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
 0.00  64.67   7.04  99.53  71.89  18293  510.574  1167 1616.594 2127.168 
91.78   7.91 100.00  99.53  72.00  18299  510.821  1167 1616.594 2127.415 
77.49   0.00   0.00  99.99  72.00  18300  510.947  1168 1616.594 2127.541 
 0.00  99.83  25.71  99.49  71.72  18305  511.178  1168 1617.915 2129.093 
24.27   0.00  21.74  99.67  71.73  18310  511.342  1168 1617.915 2129.256 
28.57   0.00   0.00  99.83  71.73  18314  511.427  1169 1617.915 2129.342 
 0.00  29.29   0.00  99.56  71.82  18317  511.465  1169 1618.919 2130.384 
 0.00  78.85  54.96  99.56  72.05  18326  511.777  1169 1618.919 2130.696 
64.52   0.00   0.00  99.99  72.05  18328  511.920  1170 1618.919 2130.839 
 0.00  99.26   0.00  99.88  71.71  18333  512.079  1171 1620.014 2132.093 
 4.86   0.00   0.00  99.95  71.76  18338  512.255  1172 1620.957 2133.211 
80.98   0.00   0.00  99.69  71.83  18350  512.453  1172 1621.906 2134.359 
 0.00  64.48   0.00  99.85  71.83  18355  512.677  1173 1621.906 2134.583 
 0.00  99.80   0.00  99.93  71.71  18359  512.876  1174 1623.264 2136.139 
 0.06   0.04 100.00  99.55  71.71  18360  512.876  1174 1624.193 2137.069 
60.35   0.00   0.00  99.90  71.77  18376  513.429  1175 1624.193 2137.622 
60.35   0.00   0.00  99.90  71.77  18376  513.429  1175 1624.193 2137.622
89.86   0.00   0.00  99.83  71.78  18384  513.839  1176 1625.476 2139.315 
89.86   0.00   0.00  99.83  71.78  18384  513.839  1176 1625.476 2139.315 
 0.00  39.17  64.41  99.60  71.78  18394  514.202  1176 1626.880 2141.082 
99.93   0.00   0.00  99.82  71.78  18396  514.326  1177 1626.880 2141.206 
 0.00  64.68   0.00  99.61  71.72  18401  514.409  1177 1627.945 2142.354 

java进程只用了1G内存:

   PID USER     PR  NI    VIRT  RES  SHR  S  %CPU  %MEM     TIME+  COMMAND
 18261 ouser    15   0   4353m 1.0g  52m  S   325  3.2  271:25.52  java
./jstat -gccapacity 18261 1000 500
 NGCMN    NGCMX     NGC     S0C   S1C       EC      OGCMN      OGCMX       OGC         OC      PGCMN    PGCMX     PGC       PC     YGC    FGC 
 87360.0 1048576.0 136256.0 65984.0 68096.0     64.0   174784.0  2097152.0   785664.0   785664.0  65536.0 524288.0  65792.0  65792.0 141612  8100
 87360.0 1048576.0 122816.0 61376.0 12992.0     64.0   174784.0  2097152.0   791360.0   791360.0  65536.0 524288.0  65792.0  65792.0 141616  8100
 87360.0 1048576.0 115264.0 57600.0 7872.0     64.0   174784.0  2097152.0   791936.0   791936.0  65536.0 524288.0  65792.0  65792.0 141617  8101
 87360.0 1048576.0 112576.0 54912.0 56256.0     64.0   174784.0  2097152.0   797952.0   797952.0  65536.0 524288.0  65792.0  65792.0 141618  8102
 87360.0 1048576.0 112576.0 54912.0 56256.0     64.0   174784.0  2097152.0   797952.0   797952.0  65536.0 524288.0  65792.0  65792.0 141618  8102
 87360.0 1048576.0 105408.0 52672.0  192.0     64.0   174784.0  2097152.0   804096.0   804096.0  65536.0 524288.0  65792.0  65792.0 141621  8103
 87360.0 1048576.0  87360.0 35584.0 38464.0   8064.0   174784.0  2097152.0   805568.0   805568.0  65536.0 524288.0  65792.0  65792.0 141629  8103
 87360.0 1048576.0 111168.0 39488.0 46080.0  12416.0   174784.0  2097152.0   805568.0   805568.0  65536.0 524288.0  65792.0  65792.0 141635  8103
 87360.0 1048576.0 142848.0 69440.0 70592.0   1664.0   174784.0  2097152.0   805568.0   805568.0  65536.0 524288.0  65792.0  65792.0 141644  8104
 87360.0 1048576.0 142848.0 69440.0 70592.0   1664.0   174784.0  2097152.0   805568.0   805568.0  65536.0 524288.0  65792.0  65792.0 141644  8104
 87360.0 1048576.0  87360.0 35136.0 37376.0  10304.0   174784.0  2097152.0   769280.0   769280.0  65536.0 524288.0  65792.0  65792.0 141661  8105

最佳答案

RES 值不是进程使用了​​多少内存,而是它使用了多少实际 RAM。这不包括交换页面和已分配但未映射的页面。确保系统本身有足够的可用内存,您可以运行 free,甚至 top 应该打印出正在使用的内存量。 top 的输出表明该进程映射了 4G 内存,但当前不在 RAM 中(VIRT 值)。

关于linux - 为什么在linux & jdk1.6.0_32中JVM不能自动扩充堆内存到配置的Xmx3072m,而且FullGC很频繁,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13999418/

相关文章:

linux - ARM 程序集创建函数

MySQL 无法写入临时目录

javascript - 为什么游戏代码继续运行而不是被垃圾收集?

java - 外部类加载Java类的内存限制

java - Java是否需要时间来调用方法?

java - 在clojure中制作一个插件系统

linux - uWSGI 配置使用 HTTPS

android - Android 中的垃圾收集器正在运行,但在 ddms 的分配跟踪器中没有显示正在分配

Java源码哈希表

linux - 自动硬链接(hard link)文件,但只有一次