这是一个创建于 2171 天前的主题，其中的信息可能已经有所发展或是发生改变。
每天基本上到了某个时间段,客户使用频繁后,线上 CPU 就会往上蹭. 我尝试使用 jstat 去查看 gc 的情况,发现当 E 区满了之后,直接 FGC, S0,S1 在这段时间永远都是 0.00, O 区基本上一直都是 99%以上的状态.
# jstat -gcutil 153221 1000 100 S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 0.00 0.00 32.73 99.33 92.54 85.47 15969 450.680 4209 15061.630 15512. 309 0.00 0.00 99.85 99.33 92.54 85.47 15969 450.680 4209 15061.630 15512. 309 0.00 0.00 76.47 99.33 92.54 85.47 15969 450.680 4210 15063.630 15512. 309 0.00 0.00 96.83 99.33 92.54 85.47 15969 450.680 4210 15063.630 15512.309 0.00 0.00 88.25 99.33 92.54 85.47 15969 450.680 4211 15065.630 15512.309 0.00 0.00 99.70 99.33 92.54 85.47 15969 450.680 4211 15065.630 15512.309 3 秒中一次 FGC,大部分 CPU 都用在 GC 线程上面. 过了这段时间后系统就会恢复正常,CPU 就会恢复稳定. 现在想请教下各位: 什么情况下会造成 Eden 区满了之后,直接触发 Full GC, 而不是 YGC. 另外,即便是现在 CPU 降下来了, gc 正常了, ps_old_gen 使用率依旧很高. (2685M/2731M), 如果是内存泄露那么不应该 CPU 一直都没法降下来吗?
请教下各位,遇到这种问题应该朝着什么方向去排查呢?
 | 1 Jooooooooo 2020 年 5 月 16 日 首先看下 jvm 配置, 是不是 s 区装不下了所以被迫直接放进 old, 算一下大小 第二是既然 gc 之后使用率很高, 那踩点 dump, 看看内存是都是什么东西, 找准业务特有相关的东西去看. 特别是还可以在低峰期正常的时候同时 dump 一份对比看看有什么对象是异常时期特有的 第三是如果某个固定时间发生这种异常一般要么是随着业务运行, 内存刚好需要做这样的调整, 要么就是存在业务特点, 分析一下那个时间段有没有特殊的业务(比如秒杀活动, 定时任务等等) 第四是看看异常时期的日志, 也辅助定位是不是存在特殊的逻辑 第五贴一下完整的 gc log, 特别是带有 young 区分代信息的 |
 | 2 Solace202 2020 年 5 月 16 日 via iPhone 没有 young gc 可能是 survivor 区放不下直接 full gc 。一楼说的对，full gc 了直接用 jamp 把堆栈 dump 下来，然后 eclipse memory analyser 工具看看啥东西一直那么多一直 full gc，然后优化代码。 |
 | 3 aizya OP @Jooooooooo GC log 能看出什么原因吗 gc log 如下所示: ``` [Full GC (Ergonomics) 3881881K->2889968K(4038144K), 4.5727780 secs] [Full GC (Ergonomics) 3881681K->2889026K(4038144K), 3.0774469 secs] [Full GC (Ergonomics) 3881614K->2888641K(4038144K), 2.2580244 secs] [Full GC (Ergonomics) 3881614K->2887646K(4038144K), 4.2011123 secs] 17:46:48,926 [Full GC (Ergonomics) 3881614K->2887135K(4038144K), 2.7401695 secs] [Full GC (Ergonomics) 3881612K->2886768K(4038144K), 4.0454051 secs] [Full GC (Ergonomics) 3881612K->2887188K(4038144K), 2.3936678 secs] [Full GC (Ergonomics) 3881608K->2887642K(4038144K), 4.0567923 secs] [Full GC (Ergonomics) 3881918K->2886507K(4038144K), 4.6593080 secs] [Full GC (Ergonomics) 3881783K->2886918K(4038144K), 4.0624945 secs] 17:47:38,528 [Full GC (Ergonomics) 3881782K->2865376K(4038144K), 0.862440 secs] [Full GC (Ergonomics) 3881694K->2865692K(4038144K), 2.9422862 secs] [Full GC (Ergonomics) [PSYoungGen: 1085440K->69778K(1241600K)] [ParOldGen: 2796159K->2796144K(2796544K)] 3881599K->2865922K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 3.3878363 secs] [Times: user=71.81 sys=0.39, real=3.39 secs] [Full GC (Ergonomics) [PSYoungGen: 1085440K->71060K(1241600K)] [ParOldGen: 2796144K->2796064K(2796544K)] 3881584K->2867125K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 4.3924844 secs] [Times: user=93.60 sys=0.58, real=4.40 secs] 17:48:10,361 17:48:13,784 17:48:13,831 [Full GC (Ergonomics) [PSYoungGen: 1085440K->78286K(1241600K)] [ParOldGen: 2796064K->2795878K(2796544K)] 3881504K->2874164K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 4.7109424 secs] [Times: user=101.27 sys=0.58, real=4.71 secs] [Full GC (Ergonomics) [PSYoungGen: 1085440K->83326K(1241600K)] [ParOldGen: 2795878K->2795708K(2796544K)] 3881318K->2879035K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 4.0158977 secs] [Times: user=85.44 sys=0.50, real=4.01 secs] [Full GC (Ergonomics) [PSYoungGen: 1085440K->82672K(1241600K)] [ParOldGen: 2795708K->2795707K(2796544K)] 3881148K->2878379K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 4.2606693 secs] [Times: user=90.71 sys=0.57, real=4.26 secs] 17:48:31,473 [Full GC (Ergonomics) [PSYoungGen: 1085440K->110615K(1241600K)] [ParOldGen: 2795707K->2795655K(2796544K)] 3881147K->2906270K(4038144K), [Metaspace: 238529K->238529K(1271808K)], 4.5355769 secs] [Times: user=96.77 sys=0.61, real=4.54 secs] ``` |
| 4 Jooooooooo 2020 年 5 月 16 日 你做下 dump 吧, 很明显 old 回收不了 |
| 5 aizya OP @Jooooooooo 问题解决了,谢谢你, 用 MAT 分析后发现问题了. |
Select Language