php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #62668 Setting "listen.backlog = -1" is not equal to "unlimited".
Submitted: 2012-07-26 17:22 UTC Modified: 2014-12-30 10:41 UTC
From: robwaa at zonnet dot nnl Assigned:
Status: No Feedback Package: FPM related
PHP Version: Irrelevant OS: Ubuntu Server 12.04 LTS (OpenVZ)
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
34 + 8 = ?
Subscribe to this entry?

 
 [2012-07-26 17:22 UTC] 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"


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-07-26 18:19 UTC] 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
 [2013-02-03 01:28 UTC] 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.
 [2013-10-28 12:59 UTC] tony2001@php.net
-Status: Open +Status: Feedback
 [2013-10-28 12:59 UTC] tony2001@php.net
Please try using this snapshot:

  http://snaps.php.net/php5.5-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/


 [2014-12-30 10:41 UTC] php-bugs at lists dot php dot net
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 07:01:28 2024 UTC