C/S model & process model:
Web server (nginx or lighttpd) as clients <--> PHP-FPM as server, forking pm.max_children PHP FCGI processes
从表面看,是PHP hang住了。引起这个现象的原因,分为两个方面。对以下这些原因的原因,没有进行分析。
php-fpm方面:
1) 当前存在的php-cgi进程数,达到了这些php-cgi对应的php-fpm的pm.max_children上限。此时,php-fpm的反应(比如php-fpm.log)和作为client的web server的反应,后续补充。
2) completely established connection队列中元素的数量,达到listen.backlog上限。此参数在php-fpm.conf中没有设置,所以由系统的somaxconn来决定。
3) incompletely established connection队列中元素的数量,达到tcp_max_sync_backlog上限。
4) php-fpm(以及php-cgi)用来listen、accept、其他操作的fd,达到rlimit_files上限。
5) OS的fd使用达到上限。
web server方面,以nginx为例:
1) nginx worker process使用的fd,达到此进程fd上线,不能再处理新请求。
2) 不确定原因导致nginx worker process异常。
3) OS的fd使用达到上限。
根据我们系统的实际运行表现,引起php hang住的实际原因应该是php-fpm方面的1、2、4条。与其相关php-fpm配置分别是:
pm.max_children 128
listen.backlog -1 (somaxconn 2048)
rlimit_files 1024
所以,如果仅从配置方面解决问题,应该提高pm.max_children的值和rmlimt_files的值,并再测试是否需要提高listen.backlog的值。
p.s. 目前线上系统的file-max是4792848,work用户的soft/hard nofile limit是32768/65535。
Web server (nginx or lighttpd) as clients <--> PHP-FPM as server, forking pm.max_children PHP FCGI processes
从表面看,是PHP hang住了。引起这个现象的原因,分为两个方面。对以下这些原因的原因,没有进行分析。
php-fpm方面:
1) 当前存在的php-cgi进程数,达到了这些php-cgi对应的php-fpm的pm.max_children上限。此时,php-fpm的反应(比如php-fpm.log)和作为client的web server的反应,后续补充。
2) completely established connection队列中元素的数量,达到listen.backlog上限。此参数在php-fpm.conf中没有设置,所以由系统的somaxconn来决定。
3) incompletely established connection队列中元素的数量,达到tcp_max_sync_backlog上限。
4) php-fpm(以及php-cgi)用来listen、accept、其他操作的fd,达到rlimit_files上限。
5) OS的fd使用达到上限。
web server方面,以nginx为例:
1) nginx worker process使用的fd,达到此进程fd上线,不能再处理新请求。
2) 不确定原因导致nginx worker process异常。
3) OS的fd使用达到上限。
根据我们系统的实际运行表现,引起php hang住的实际原因应该是php-fpm方面的1、2、4条。与其相关php-fpm配置分别是:
pm.max_children 128
listen.backlog -1 (somaxconn 2048)
rlimit_files 1024
所以,如果仅从配置方面解决问题,应该提高pm.max_children的值和rmlimt_files的值,并再测试是否需要提高listen.backlog的值。
p.s. 目前线上系统的file-max是4792848,work用户的soft/hard nofile limit是32768/65535。