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

c) **分析nginx upstream响应时间

结论：

通过上图发现nginx upstream 响应时间有增加，目前猜测可能后端upstream响应时间拖住nginx，导致nginx出现请求流量异常。

10.3 分析系统CPU情况

a) **通过top观察系统指标

top 

结论：

发现nginx worker cpu比较高

b) **分析nginx进程内部cpu情况

perf top -p pid 

结论：

发现主要开销在free,malloc,json解析上面

10.4 火焰图分析CPU

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

【编辑推荐】

1. 如何在Linux中添加新磁盘
2. 云开发与WePY，快速实现Linux命令查询小程序
3. Linux系统线上故障排查的几种技巧
4. 10款你可以通过Wine在Linux上玩的游戏
5. 使用Arch Linux镜像列表管理器来管理你的镜像

（编辑：ASP站长网）