1

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

Tenured 代的使用率为 99%，并为 FullGC 提供了非常频繁的使用频率。Java 进程仅使用 1G 内存，如top.

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

这 2 个参数也是默认的：

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 657102.0 141612 8
 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 8
 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 8
 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 8
 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 8
 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 810
 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 657192.0 141629
 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 14136
 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 657804.0 141644
 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 657804.0 141644
 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 6571052.0 141616
4

3 回答 3

1

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

于 2012-12-22T02:58:01.733 回答
0

你能检查你-XX:+UseAdaptiveSizePolicy的设置吗？默认情况下它应该是打开的。

此外，您可能将其设置得太小Xms，以至于 GC 无法在如此短的时间内恢复和调整堆区域的大小。你能试试例如-Xms1024m -Xmx3072mand-Xms2048m -Xmx3072m吗？在这些情况下，GC 是否设法正确调整大小？（动态监控jstat -gccapacity在这里可能会有所帮助。）

一般来说，UseAdaptiveSizePolicy是有帮助的，并且算法能够调整堆人体工程学。但是，用户的主要责任始终是观察应用程序的内存分配行为并根据其最佳利益设置 GC 参数。这很可能只是-Xms256m -Xmx3072m不足以跟上您的分配率和实时数据集的大小。

顺便提一句。我认为系统内存没有问题，因为当您从一开始就给它足够的内存（例如-Xms3072m -Xmx3072m）时，GC 表现良好。

于 2012-12-22T12:38:21.200 回答
-1

我认为您的 JVM 命令行选项是正确的。也许你有错误的方式来监控 JVN 堆。

VIRT是进度要求的整个空间，如果空间不够，可能会使用swap。

也许您可以使用jstat -gccapacity 18261 1000 500观察世代容量及其对应空间的统计信息。

gc     Garbage-collected heap statistics
+-------+-------------------------------------------+
|Column |                Description                |
+-------+-------------------------------------------+
|SOC    | Current survivor space 0 capacity (KB).   |
|S1C    | Current survivor space 1 capacity (KB).   |
|S0U    | Survivor space 0 utilization (KB).        |
|S1U    | Survivor space 1 utilization (KB).        |
|EC     | Current eden space capacity (KB).         |
|EU     | Eden space utilization (KB).              |
|OC     | Current old space capacity (KB).          |
|OU     | Old space utilization (KB).               |
|PC     | Current permanent space capacity (KB).    |
|PU     | Permanent space utilization (KB).         |
|YGC    | Number of young generation GC Events.     |
|YGCT   | Young generation garbage collection time. |
|FGC    | Number of full GC events.                 |
|FGCT   | Full garbage collection time.             |
|GCT    | Total garbage collection time.            |
+-------+-------------------------------------------+
于 2012-12-22T05:09:40.413 回答