Bug #62668 [Fbk->NoF]: Setting "listen.backlog = -1" is not equal to "unlimited".

Edit report at https://bugs.php.net/bug.php?id=62668&edit=1 ID: 62668 Updated by: php-bugs@lists.php.net Reported by: robwaa at zonnet dot nnl Summary: Setting "listen.backlog = -1" is not equal to "unlimited". -Status: Feedback +Status: No Feedback Type: Bug Package: FPM related Operating System: Ubuntu Server 12.04 LTS (OpenVZ) PHP Version: Irrelevant Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: ------------------------------------------------------------------------ [2013-10-28 12:59:30] tony2001@php.net Please try using this snapshot: http://snaps.php.net/php5.5-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ------------------------------------------------------------------------ [2013-02-03 01:28:19] robwaa at zonnet dot nl Thanks for absolutely nothing. Zilch, zero, nada, zip. I resolved the problem by first dumping PHP-FPM. Then dumping PHP. ------------------------------------------------------------------------ [2012-07-26 18:19:11] robwaa at zonnet dot nnl In Description, that should have been : "I was getting 500-580 of this error **at the start** of each swamp test of the webserver," The number following 5xx= (see screenshot) was consistent with the number of socket errors each and evey time. Screenshot of the short load test result : http://i50.tinypic.com/i2nlaf.png ------------------------------------------------------------------------ [2012-07-26 17:22:11] robwaa at zonnet dot nnl Description: ------------ Versions root@vpg:~# php5-fpm -v PHP 5.3.10-1ubuntu3.2 (fpm-fcgi) (built: Jun 13 2012 17:23:57) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH root@vpg:~# nginx -v nginx version: nginx/1.2.2 (with apt-get from the bottom of this page http://nginx.org/en/download.html) I was getting 150-200 of this error **at the start** of each swamp test of the webserver. The time was the same up to and including the second for each batch of error messages. From the Nginx error.log : 2012/07/25 05:46:06 [error] 388#0: *4293 connect() to unix:/run/php-fpm/vpg-fpm.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: domainname.com, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/vpg-fpm.socket:", host: "domainname.com" In this case the first successful connect would be at 05:46:07 (nginx access.log). According to /etc/php5/fpm/pool.d/www.conf : "; Set listen(2) backlog. A value of '-1' means unlimited." "; Default Value: 128 (-1 on FreeBSD and OpenBSD)" So I set "listen.backlog = -1". The error persists. Checked with all sorts of combinations, and from ondemand, to dynamic, to static, back to ondemand. But, the error persists. Then I checked the /var/log/php5-fpm.log : "WARNING: [pool vpg] listen.backlog(-1) was too low for the ondemand process manager. I updated it for you to 128." "NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful" "WARNING: [pool vpg] listen.backlog(-1) was too low for the ondemand process manager. I updated it for you to 128." 1) Value "-1" is not interpreted as "unlimited", but raises a warning. 2) "listen.backlog" is then initialized to the low default of 128. Not what I expected. Test script: --------------- No script provided. - Set "listen.backlog = -1" in /etc/php5/fpm/pool.d/www.conf. - Use Unix Sockets between Nginx + php-fpm. With or whithout APC, doesn't matter. - Load test Nginx + php-fpm. - Check php-fpm's error log for the warning about "listen.backlog". - Check Nginx's error.log for the Unix Socket connect() errors and note their time. Should all be the same. - Check Nginx's access log and find the first response with status 200, to determine if the connect errors happened just before it. I used autobench, httperf, and ab. This very very short load test, should last about 20 - 25 seconds from VPS to VPS. But was enough to trigger the result. : httperf --timeout=30 --client=0/1 --server=vectorplayground.com --port=80 --uri=/info.php --rate=2000 --send-buffer=4096 --recv-buffer=16384 --num-conns=2000 --num-calls=1 Expected result: ---------------- For "listen.backlog = -1" to be "unlimited", I would have expected php-fpm, on Nix, to always look at the values of "net.core.somaxconn" and "net.core.netdev_max_backlog". And then to initialize itself to somewhere near, or equal to "net.core.somaxconn". My VPS's "net.core.somaxconn" is set at 4096, and I set "listen.backlog = 3072". Gone were the Unix Socket connect errors. When Unix Sockets are used, you might want to initialize to a much higher default than 128, if net.core.somaxconn permits. Or at least make a remark to do so, in the comments. This is about a backlog. I can imagine the problem being even bigger with the ondemand mode on slower hardware. Actual result: -------------- First from php-fpm during its start up : "WARNING: [pool vpg] listen.backlog(-1) was too low for the ondemand process manager. I updated it for you to 128." "NOTICE: configuration file /etc/php5/fpm/php-fpm.conf test is successful" "WARNING: [pool vpg] listen.backlog(-1) was too low for the ondemand process manager. I updated it for you to 128." From Nginx at the start of the load test : 2012/07/25 05:46:06 [error] 388#0: *4293 connect() to unix:/run/php-fpm/vpg-fpm.socket failed (11: Resource temporarily unavailable) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: domainname.com, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm/vpg-fpm.socket:", host: "domainname.com" ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=62668&edit=1