一、问题分析
1、分析php-fpm.slow.log发现没有执行慢的地方，然后把目光放到了nginx 与php建立连接的阶段上，使用tcpdump在服务器上抓包，
发现性能差的机器上存在大量的SYN3秒超时，并且会伴有请求头的超时重传。如下图：
看来凶手已经找到了：是SYN 超时。一般SYN 超时是由于服务端backlog引起的，在我们的应用中，nginx –> php-fpm，所以php-fpm相当于服务端，查看php-fpm配置发现 backlog值是 -1
抱着试试看的心态，改变了fpm配置backlog的值，测试发现把php-fpm的backlog值设为：10 –262143 之间机器的性能恢复了（1-10因为太小，所以性能不太理想），但是只要大于262144，性能就又变差了。结合上面的问题，SYN超时一般是服务器端完成连接队列满导致的， 既然backlog值被设置成了somaxconn，那么不应该出现内核中完成连接队列满的情况。
从上面的测试我们可以认为php-fpm是因为没有及时accept连接导致服务器不再接收TCP连接导致的，那么fpm为什么会不及时accept呢？
原来fpm 多个进程是监听同一个套接字的，通过一个套接字锁来保证同一时刻只有一个进程可以accept，多进程间抢锁是需要消耗时间的，
在backlog被设置成-1的情况下，如果fpm没有及时accept，那么在并发量很大的情况下势必会出现SYN 超时重连了。
二、结论
综上：性能差是由于php-fpm backlog参数设置为-1，导致fpm没能及时取出完成连接队列的socket，出现SYN 超时，最终导致压不上去，表现出性能差。
所以安装php-fpm时backlog一定要重新设置，不能用fpm默认配置的-1 ，可以根据机器的并发量来设置，建议设置在1024以上，最好是2的幂值（因为内核会调整成2的n次幂）。
如果您的业务机是2.6.18内核，同时发现php 机器性能特不合理，那么就试试改一下fpm的backlog参数吧，您肯定会震惊的。。。。
三、备注
在2.6.32内核上测试就不会出现这个问题，因为2.6.32内核给listen socket分配空间时做了特殊的处理：
四、遗留问题
虽然问题解决了，但是还存在两个疑问。
1、虽然通过测试可以确定backlog设置很大会出现SYN超时，但是还不能从原理上解释？
2、为什么同样设置的-1，有的机器性能很好，有的却很差呢？
《本文》有 0 条评论