服务器CPU-100%-原因排查

找到最耗CPU的进程

* top -c ，显示进程运行信息列表
* java应用可以用 jps或者ps -ef|grep java命令
* 键入P (大写p)，进程按照CPU使用率排序

找出最耗CPU线程

* top -H -p 10765(上面命令查询到进程号) ，显示一个进程的线程运行信息列表
* 键入P (大写p)，线程按照CPU使用率排序

将线程PID转化为16进制

* printf “%x” 10804
* 结果: 0x7a0a
* 备注:之所以要转化为16进制，是因为堆栈里，线程id是用16进制表示的。

查看堆栈，找到线程在干嘛

* 工具 pstack/jstack/grep
* jstack 10765 | grep ‘0x2a34’ -C5 --color
* 也可以将堆栈信息先保存下来，生产服务先恢复后，再去排查日志。jstack -l 10765 > java_stack.log
* 打印进程堆栈,通过线程id，过滤得到线程堆栈

堆栈日志

分析程序线程对应代码

• 如果对应的代码是业务代码，考虑常见的死循环，慢sql等问题
• 如果对应的代码是gc线程日志，需要修改jvm参数，将jvm日志保存下来分析。
• 参考：

-Xmx4096M -Xms4096M -Xmn1536M -XX:MaxMetaspaceSize=512M -XX:MetaspaceSize=512M -XX:+UseSerialGC -XX:ErrorFile=/home/admin/iot/jvm/hs_err_pid%p.log   -Xloggc:/home/admin/iot/jvm/gc.log -XX:HeapDumpPath=/home/admin/iot/jvm -XX:+PrintGCDetails -XX:+PrintGCDateStamps -verbose:class -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC -XX:+PrintHeapAtGC