Linux问题故障定位，看这一篇就够了

a) **生成用户态CPU火焰图

//on-CPU user 
sh ngx_on_cpu_u.sh pid 
 
//进入结果目录 
cd ngx_on_cpu_u 
 
//开一个临时端口8088 
python -m SimpleHTTPServer 8088 
 
//打开浏览器输入地址 
127.0.0.1:8088/pid.svg 

结论：

发现代码里面有频繁的解析json操作，并且发现这个json库性能不高，占用CPU挺高。

10.5 案例总结

a) 分析请求流量异常，得出nginx upstream后端机器响应时间拉长。

b) 分析nginx进程cpu高，得出nginx内部模块代码有耗时的json解析以及内存分配回收操作。

10.5.1 深入分析

根据以上两点问题分析的结论，我们进一步深入分析。

后端upstream响应拉长，最多可能影响nginx的处理能力。但是不可能会影响nginx内部模块占用过多的cpu操作。并且当时占用cpu高的模块，是在请求的时候才会走的逻辑。不太可能是upstram后端拖住nginx，从而触发这个cpu的耗时操作。

10.5.2 解决方式

遇到这种问题，我们优先解决已知的，并且非常明确的问题。那就是cpu高的问题。解决方式先降级关闭占用cpu过高的模块，然后进行观察。经过降级关闭该模块cpu降下来了，并且nginx请求流量也正常了。之所以会影响upstream时间拉长，因为upstream后端的服务调用的接口可能是个环路再次走回到nginx。

11.参考资料

http://www.brendangregg.com/index.html

http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

http://www.brendangregg.com/FlameGraphs/memoryflamegraphs.html

http://www.brendangregg.com/FlameGraphs/offcpuflamegraphs.html

http://www.brendangregg.com/blog/2014-11-09/differential-flame-graphs.html

https://github.com/openresty/openresty-systemtap-toolkit

https://github.com/brendangregg/FlameGraph

https://www.slideshare.net/brendangregg/blazing-performance-with-flame-graphs

（编辑：3v站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!