背景
通过性能监控发现上线服务器cpu某核占用率已经达到了100%,而且是由我们的某个核心服务导致的。幸亏由于我们的服务进程由多个相同worker(线程)调度承担的,所以除了CPU占用率高之外,并没有对服务造成影响。随着上次我们找到那个吃IO的罪犯,这次我们要追捕的是潜伏在团体中的特务,更加惊险刺激哟!
系统环境
![](https://i-blog.csdnimg.cn/blog_migrate/14b2ad0065ed1a4ca17340babe5c1f38.png)
用top命令很容易定位到是谁占用CPU最高。
![](https://i-blog.csdnimg.cn/blog_migrate/8106fe531931f9de0be49de088f301ef.jpeg)
以我们的这个业务进程(imDevServer)举例,为什么说这货是个潜伏者呢?因为这是个多线程的进程,我们要知道实际上占用cpu的最小单位是线程,所以肯定是众线程中的某一个或几个占用CPU过高导致的。再用top -H -p pid命令查看进程内各个线程占用的CPU百分比。
![](https://i-blog.csdnimg.cn/blog_migrate/e7f13381aa6da31d55573102732ed0a3.jpeg)
如上图所示我们可以看出id为8863的线程cpu占用率最高。好,我们现在只要能找到他偷走的cpu就好了,虽然这小子嘴巴严,但是我们有一套完善的审问流程,不怕他不招。首先出马的是strace -T -r -c -p pid命令
![](https://i-blog.csdnimg.cn/blog_migrate/9b6bb2cc587972b087a43b5827f17f02.png)
它的作用是查看系统调用和花费的时间,epoll_wait虽然占用的调用时间多,但是他本身是个正常的阻塞调用。我们接着让pstack pid出马
![](https://i-blog.csdnimg.cn/blog_migrate/d4a44eb86faf32c4bdd04515fbcb09d9.jpeg)
可以看到每个线程的调用堆栈,找到已经找出的占用CPU最高的那个线程,然后看他的调用堆栈,很容易看出在哪一步逻辑上导致了busy loop,再使用trace -p tid看看线程的调用过程接着定位到代码,修复bug,找回被偷走的cpu。