生产环境 CPU 高，定位发现是 oracle jdk7.79 的 GC 导致，只是很奇怪是 SYS 高， USR 不高
tchekai704 2015-11-02 10:40:33 +08:00 4097 次点击这是一个创建于 3699 天前的主题，其中的信息可能已经有所发展或是发生改变。
这个情况出现好多次了， 一直没有找到原因。
环境
CPU ： E5-2630 x 2, 一共 16C32T
RAM: 128GB
jdk ： 1.7.79
class ： 1.6 版本编译的
启动参数： java -server -Xms6g -Xmx6g -Xmn3g -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+PrintGCDetails -XX:+PrintGCDateStamps
使用 top 发现 CPU 的 SYS 高达 75-100 ， USR 是 0;
top （每个进程的 cpu 达到饿了 1700%）
8974 bigdata 20 0 49.1g 6.1g 172m S 1719.3 4.9 62:06.84 java -server -Xms6g -Xmx6g -Xmn3g -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+PrintGCDetails -XX:+PrintGCDateStamps
9322 bigdata 20 0 47.2g 5.8g 176m S 1719.3 4.6 62:34.35 java -server -Xms6g -Xmx6g -Xmn3g -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+PrintGCDetails -XX:+PrintGCDateStamps
8512 bigdata 20 0 31.0g 5.7g 85m S 1719.0 4.5 57:15.66 java -server -Xms6g -Xmx6g -Xmn3g -XX:MaxPermSize=256m -XX:ParallelGCThreads=6 -XX:+PrintGCDetails -XX:+PrintGCDateStamps
jstat -gccause 8512
S0 S1 E O P YGC YGCT FGC FGCT GCT LGCC GCC
0.00 99.98 74.00 84.30 98.17 75 577.074 0 0.000 577.074 Allocation Failure No GC
0.00 0.00 5.37 18.68 50.50 76 577.098 1 0.132 577.230 Heap Dump Initiated GC No GC
贴上最后几排的 GC 日志
2015-11-01T10:51:24.235+0300: 173162.712: [GC [PSYoungGen: 3080305K->47656K(3055104K)] 5463481K->2471820K(6200832K), 0.1943950 secs] [Times: user=0.12 sys=0.95, real=0.19 secs]
2015-11-02T03:27:25.803+0300: 232924.280: [GC [PSYoungGen: 3037736K->50218K(3040768K)] 5461900K->2506926K(6186496K), 0.0715950 secs] [Times: user=0.08 sys=0.27, real=0.07 secs]
2015-11-02T04:14:34.642+0300: 235753.119: [GC [PSYoungGen: 3040298K->83946K(2973696K)] 5497006K->2613726K(6119424K), 3.1987270 secs] [Times: user=1.12 sys=5.43, real=3.20 secs]
2015-11-02T04:34:16.867+0300: 236935.344: [GC [PSYoungGen: 2973674K->127976K(3017728K)] 5503454K->2779766K(6163456K), 568.6952080 secs] [Times: user=0.00 sys=3378.32, real=568.60 secs]
简单分析了一下啊，没有发生 FULL GC, 只有 young gc ， gc 时 cpu 居高不下，一般出现在几个进程同一时刻发生 gc 时， sys 占用很高， usr 占用很低，百思不得其解。 还望各位不吝啬赐教
第 1 条附言 2015-12-22 14:45:48 +08:00
上面的日志没什么用，最后问题解决。原因是因为开启了 linux 的 zone reclaim 模式，关闭后立竿见影， cpu 恢复正常。
主要用 sar ， perf 工具定位，进程特点是除了正常的 heap 开销外， mmap 打开文件也很多（ solr ）。
以上， by Kai
2015-12-22
主要用 sar ， perf 工具定位，进程特点是除了正常的 heap 开销外， mmap 打开文件也很多（ solr ）。
以上， by Kai
2015-12-22
 | 1 aheadlead 2015-11-02 10:51:10 +08:00 Perm 区貌似满了…… |
| 2 aheadlead 2015-11-02 10:52:29 +08:00 或许是卡在 IO 上或者是线程数飙高了… |
 | 3 denghongcai 2015-11-02 10:52:31 +08:00 楼上正解，你机器如此大的内存给 JVM 这么一点…… 可以选择升级到 Java 8 ，就没 Perm 区的困扰了 |
| 4 aheadlead 2015-11-02 10:54:58 +08:00 小弟不才，可以这么试着看看线程数： $ jstat -J-Djstat.showUnsupported=true -snap 8512 | grep java.threads |
| 5 aheadlead 2015-11-02 10:56:29 +08:00 @denghongcai 一台机器跑好几十个 jvm 我也见过…… |
 | 6 tchekai704 OP @aheadlead perm 区确实满了，但是如果 perm 区满了导致 gc （不知道是 full 还是 young gc ），不应该导致 sys 占用那么多。 |
| 7 tchekai704 OP @denghongcai 其实内存不能再给多了， perm 区原来 128m ，现在 256m ； 6gb 这样的进程每个机器上有 6 个，还有 5 个 8gb 的其他进程； 因为磁盘 io 性能也很重要，所以预留很多给操作系统的 buffer 和 cache 。 |
 | 8 hellojinjie 2015-11-02 11:03:06 +08:00 换 G1 GC 嘛。。。很好用的， cpu 马上下来 |
| 9 aheadlead 2015-11-02 11:03:29 +08:00 @tchekai704 所以我猜是不是线程数飙上去了或者卡在了各种 IO |
| 10 tchekai704 OP @aheadlead iostat 看几乎是闲置的。再者 gc 和 io （磁盘）应该也没关系的呀 |
| 11 aheadlead 2015-11-02 11:29:00 +08:00 @tchekai704 好吧… |
| 12 tchekai704 OP @hellojinjie 感谢，需要测试后才能往生产环境上部署。目前还是想看一下到底哪出问题了。 |
 | 13 HentaiMew 2015-11-02 13:37:19 +08:00 我靠这么小气…简直难以想象 jvm 的心情。。。 嗯某楼说的对，可以测试下 java8 |
 | 14 anexplore 2015-11-02 18:45:37 +08:00 vmstat 看一下系统状态，比如上下文切换等；再就是减小 gc 并发数，看是否有明显变化。我遇以前也遇到过 java 进程 cpu 到 1000+，当时是 gc 并行数太高；假如每个进程中的每个 gc 线程跑到 100%， 6 个 gc 线程并行那就是 600%了。 |
| 15 tchekai704 OP @anexplore 并行数设置是 6 ， 这在 16C32T 的系统里面应该是比较小的前几天这个值是 15 ，我调小了一些。似乎并没有解决 sys 高的问题。 |
| 16 tchekai704 OP 自己顶个贴 |
Select Language