cpu 真的飙到270%,一次很好的排查体验

场景: 来自一次真的排查过程,运营经理在dashborad下载一家门店图片,下载了10多分钟(平时基本1分钟搞定的),了解情况后,自己上正式环境看看,首选看的就是cpu,发现该项目所占的cpu已经达到了270%(4核),而且没有下降的趋势,于是看了一下该项目的运行日志,发现打印的确实是图片下载这一环节的信息,自己又开始回想,之前在预发布环境测试过下载100多家门店也没有这么慢,想想发现最近有个紧急需求(就是给下载的图片加水印的步骤,感觉顿时一阵凉凉),好吧,问题已经找出来啦,现在我们也在demo中模拟该情况下怎么定位到问题出在哪里。

1.使用top 查看 进程,确定 PID(哪个项目进程)

2.使用 ps -ef |grep 12524 或者 jps |grep 12524 确定是不是我们的项目


3. 使用 ps -mp 12524 -o THREAD,tid,time (查找tid)



4.确定了tid 为 22971 的线程 ,cpu占用率达到 98.5, 接下来 使用 :printf "%x\n" tid(将 tid转换成十六进制)


5.jstack pid |grep -A 10  tid(用16进制 转换,-A 表示 打印后10数据)


6.通过上面已经知道是哪个类,哪个方法出了问题,这是我们直接去项目工程中定位到这个方法

(idea  可以使用快捷键  ctr+shift+alt+n)查看方法内容


7.确定有可能是这个循环创建对象的程序有问题,这时可以查到程序的日志,通过

grep  “rows”  日志.log.  既然可以看到 column的值这么大,这时你应该想到是怎么回事啦,赶紧改代码吧。


总结: 就这次的排查过程,让我清楚到了怎么去定位问题。希望大家也能够学会。


无敌TG , 给小编一个赞吧

你可能感兴趣的:(cpu 真的飙到270%,一次很好的排查体验)