一、问题分析

 

       1、分析php-fpm.slow.log发现没有执行慢的地方,然后把目光放到了nginx 与php建立连接的阶段上,使用tcpdump在服务器上抓包,

 

发现性能差的机器上存在大量的SYN3秒超时,并且会伴有请求头的超时重传。如下图:

php-fpm backlog参数优化_套接字

        看来凶手已经找到了:是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,有的机器性能很好,有的却很差呢?