nginx+php-fpm故障排查

$ strace -cp $(pgrep -n nginx)

$ top

$ lsof | more

遂怀疑是连接创建关闭消耗了太多的资源，
便让小明加了台机器专门跑nginx，
前端挂了个nginx用长连接跟后端的nginx
连接。接了个nginx之后负载果然就下来了。
前端未挂nginx压测ab压测结果:


前端挂了nginx压测ab压测结果:
tps基本没变第一个Time per 
requset快了87.52%。
接着继续排查tps上不去的原因，
继续strace后端的nginx。$ strace -cp $(pgrep -n nginx)发现现在是wrtiev占用高了，
strace 跟踪close的系统调用，
发现很多以下的输出：
connect(26, {sa_family=AF_INET, 
sin_port=htons(9000), 
sin_addr=inet_addr("127.0.0.1")},
 16) = -1 EINPROGRESS
 (Operation now in progress)问题应该不是在nginx上，
应该是在php-fpm上了。继续$ strace -cp $(pgrep -n php-fpm)显示下图所示：access cpu时间消耗最多那就先
排查access
系统调用：
$ strace -T -ttp 
$(pgrep -n php-fpm) 2&>1 |
grep -B 10 access >
 ./access.log
php-fpm进程频繁的去读取文件，整个操
作下来花费4ms的时间。然后排查recvfrom：
$ strace -T -ttp $(pgrep -n 
php-fpm) 2&>1 |
grep -B 10 recvfrom > 
./recvfrom.log频繁的去访问10.0.0.156的6379,端口，
明显就是访问redis读取数据的过程，
整个过程花费12ms。
让小明把上面两个strace信息发给开发，
第一个得到回复是老版本的流程，
新版本改了，但还是有些判断没有处理。
第二个问题让开发使用redis连接池，
无需频繁创建连接读取数据，
频繁创建连接开销很大的。
总结
当遇上性能问题时，排查日志无法解决时，
使用strace工具来查看一下系统调用，
看时间到底消耗在哪里了，
可以轻松的找到问题所在。