1.获取cpu过高的进程
通过top命令获取 top进入界面后 通过shift+p 获取cpu从高到底的进程
获取cpu过高线程
方法1:通过top获取
通过 top -p -H 查看当前进程内的线程及所占cpu信息(ps:)
如下所示 top -Hp 30872
如上图所示，linux下，所有的java内部线程，其实都对应了一个进程id，也就是说，linux上的sun jvm将java程序中的线程映射为了操作系统进程；我们看到的进程id对应java线程信息中的’nid’(‘n’ stands for ‘native’);
方法2:通过ps获取
ps -mp -o THREAD,tid,start,etime| sort -rn(按数字倒排序也可增加栏位k那就同时增加-t分隔符这里-rn就可) | more 获取pid下对应的线程信息及线程tid
查看百分比最高的几个线程id
sorry后补充的没有用这个
获取对应的线程id
printf “%x\n” tid 获取到线程id
分析占用cup高的线程
在通过jstack 获取对应的线程栈信息
jstack -l > xxx.tdump
记得多dump几个镜像,之后可以通过jvisualvm 载入分析对应的线程 找到对应的线程进行分析
我自己down下来了使用jstack -l > jstack-app.tdump
然后采用less jstack-app.tdump | grep id 以下为结果
通过上图发现 四个占用cup的都是回收线程
分析内存
- 获取堆
jmap -dump:format=b,file=app.1.hprof 30872
通过eclipse memory analyzer工具进行分析
下载地址 https://pan.baidu.com/s/1BQpDQThO7HNa_x7s2Snowg
查看存活大对象
点开其中的一个线程 发现如下图
因为采用的的是jetty作为容器,发现这些都是运行的请求线程,因为请求加载的资源太大造成的 问题就排查出来了.
内存设置太小 才500m 后续增加内存 该情况得到缓解
以上是排查流程 如有后续遇到实际问题并可截图的会给予实操截图分析
参考:https://blog.csdn.net/hanghangaidoudou/article/details/51488249