为什么JVM不能将堆内存自动扩展到linux&；中配置的Xmx3072m；jdk1.6.0_32和FullGC经常出现_Linux_Garbage Collection_Jvm

为什么JVM不能将堆内存自动扩展到linux&；中配置的Xmx3072m；jdk1.6.0_32和FullGC经常出现

linux jvm

为什么JVM不能将堆内存自动扩展到linux&；中配置的Xmx3072m；jdk1.6.0_32和FullGC经常出现,linux,garbage-collection,jvm,Linux,Garbage Collection,Jvm,为什么在linux和jdk1.6.0_32中JVM内存不能自动扩展到Xmx3072m 终身使用的一代使用率为99%，并且借给FullGC的频率非常高。java进程只使用1G内存，这可以从top的输出中看出如果我们将JVM参数更改为-Xms3072m-Xmx3072m，那么它可以正常工作。但是如果我们使用-Xms256m-Xmx3072m，那么问题就会出现，并且FullGC经常发生这两个参数也是默认值： MinHeapFreeRatio 40 MaxHeapFreeRatio 70

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

终身使用的一代使用率为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-总容量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

值）。

我认为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.            |
+-------+-------------------------------------------+

您能检查您的

-XX:+UseAptiveSizePolicy

是否已设置？默认情况下，它应该处于启用状态

此外，您可能会给它太小的

Xms

，因此GC无法在如此短的时间内恢复堆区域并调整其大小。您可以试试例如

-Xms1024m-Xmx3072m

和

-Xms2048m-Xmx3072m

？在这些情况下，GC是否能够适当调整尺寸？（实时监控

jstat-gccapacity

可能会有所帮助。）

一般来说，

useAptiveSizePolicy

是有用的，并且该算法能够调整堆的人体工程学。但是，主要的责任始终在于用户观察应用程序的内存分配行为，并根据自己的最佳利益设置GC参数。很可能是

-Xms256m-Xmx3072m

根本不足以跟上您的分配率和实时数据集的大小

顺便说一句，我认为系统内存没有问题，因为当您从一开始就给GC足够的内存时（例如，

-Xms3072m-Xmx3072m

），GC表现良好。

但是为什么如果我们将JVM参数更改为-Xms3072m-Xmx3072m，那么它工作正常呢。如果我们使用-Xms256m-Xmx3072m，那么问题就会出现，而且FullGC发生得非常频繁？是否有可用的RAM？JVM不会尝试使用不可用的内存，除非您强制使用，因为您将进入交换抖动，在大多数情况下，它的性能比GC差。@linux wgvb:/opt/jdk/jdk1.6.0_32/bin>缓存的空闲共享缓冲区的空闲总使用量Mem:32937336 2885076 40867600 259204 18551848
-/+buffers/cache:10039524 22897812
交换：2104472 328762071596@linux-wgvb:/opt/jdk/jdk1.6.0_32/bin>top-top-top-14:32:06最多8天，22:23，7个用户，平均负载：12.30，15.25，16.44任务：总共344个，1个运行，343个睡眠，0个停止，0个僵尸Cpu：35.3%美国，4.9%sy，0.0%ni，56.7%id，3.0%wa，0.0%hi，0.1%si，0.0%st Mem:32165M总数，28204M使用，3960M空闲，253M缓冲区交换：总共2055M，使用32M，2023M空闲，18117M缓存，所以您确实有22G空闲（18个带有可丢弃缓存数据）@linux wgvb:/opt/jdk/jdk1.6.0_32/bin>/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 87360.0 34688.0 32896.0 19776.0 174784.0 2097152.0 599104.0 599104.0 65536.0 524288.0 65792.0六万五千七百九十二点零一三二五七六

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.            |
+-------+-------------------------------------------+