项目部署以后出行卡顿现象，所以对问题进行了排查，记录一下排查过程
1.找进程
top
可以发现，是Java进程导致的CPU过高，致使系统卡顿
2.找线程
ps -mp pid -o THREAD,tid,time
发现占比最大的线程
3.线程id转换16进制
printf “%x\n” pid
得到6a33，方便下一步排查
4.查询代码位置
jstack pid|grep tid -A 30
发现全是GC线程
5.查看gc频率
jstat -gcutil pid 时间间隔 打印次数
发现Eden很满，不断增长，GC次数过多
垃圾回收统计
S0: Survivor space 0 utilization as a percentage of the space’s current capacity. 幸存者区0
S1: Survivor space 1 utilization as a percentage of the space’s current capacity. 幸存者区1
E: Eden space utilization as a percentage of the space’s current capacity. 伊甸园区
O: Old space utilization as a percentage of the space’s current capacity. 老年代
M: Metaspace utilization as a percentage of the space’s current capacity. 元空间
CCS: Compressed class space utilization as a percentage. 压缩类空间利用率为百分比。
YGC: Number of young generation GC events. 年轻一代GC事件的数量。
YGCT: Young generation garbage collection time. 年轻一代垃圾收集时间
FGC: Number of full GC events. 完整的GC事件的数量。
FGCT: Full garbage collection time. 完全垃圾收集时间。
GCT: Total garbage collection time. 垃圾回收总时间。
jstat -gccapacity pid
堆内存查看
NGCMN：新生代最小容量
NGCMX：新生代最大容量
NGC：当前新生代容量
S0C：第一个幸存区大小
S1C：第二个幸存区的大小
EC：伊甸园区的大小
OGCMN：老年代最小容量
OGCMX：老年代最大容量
OGC：当前老年代大小
OC:当前老年代大小
MCMN:最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：年轻代gc次数
FGC：老年代GC次数
6.dump堆文件
jstack pid >>jstack.out
7.查找dump文件
find . -name “jstack.out”
这步可有可无，生成在当前目录
8.IBM Thread and Monitor Dump Analyzer for Java
可视化工具分析dump文件
查看结果还算正常
9.尝试调整JVM参数
查看JVM参数，发现默认才512m
查看系统总内存
cat /proc/meminfo查看linux系统内存大小的详细信息
发现总内存约64G
将-Xmx 最大堆内存设置为1024m，扩大一倍看看
重启服务发现GC频率明显下降，恢复正常，满足以下标准
如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1〜3 秒，或者频繁G C
,则必须优化。如果满足下面的指标，则一般不需要进行GC: ■ Minor GC执行时间不到50ms; ■ Minor
GC执行不频繁，约10秒一次； ■ Full GC执行时间不到1s; ■ Full GC执行频率不算频繁，不低于10分钟1次。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/93765.html
