1

On a setup using nginx with PHP-FPM v5.3.3, I noticed the following errors occurring frequently in the nginx' errors log:

Feb 16 15:00:22 mymachine www.example.com 2015/02/16 15:00:20 [error] 20254#0:
*1448249 readv() failed (104: Connection reset by peer) while reading upstream
[...]

Looking at the php-fpm.log file, I noticed the following:

[16-Feb-2015 15:00:20] NOTICE: [pool www] child 22279 exited with code 0 after
47983.681002 seconds from start
[16-Feb-2015 15:00:20] NOTICE: [pool www] child 10625 started

That is worker recycling as the pm.max_requests configuration directive sets.

I (reasonably) assumed PHP-FPM would courrectly process any accepted connection/request before recycling the worker, as this task does not imply any kind of emergency.

  1. Is it a misconfiguration?
  2. Is it a flaw of PHP-FPM 5.3.3?
  3. Is it a flaw of all version of PHP-FPM?
Improve this question
3
  • 1
    Have you only got one worker? Why have you run such an old version of PHP?
    – Michael Hampton
    Feb 16, 2015 at 17:04
  • Nope, several workers with light load. I noticed this problem happening several times with the same symptoms, hence I only provided the relevant log snippets.
    – Bernard Rosset
    Feb 17, 2015 at 8:23
  • Old version of PHP is historical, and I have no direct control over it. These problems will add up to the list of points encouraging an upgrade of the infrastructure. ;)
    – Bernard Rosset
    Feb 17, 2015 at 8:33

1 Answer 1

Reset to default
1
  1. No. It's valid.
  2. May be. You should really consider upgrading at least on last 5.3.x, but it's better to upgrade to some recent 5.x, since 5.3.x isn't supported anymore.
  3. Nope. I had such configuration working on all versions. Furthermore, having pm.max_requests set is a common practice.

May be you just have to few workers running. You should really investigate the number of busy and running workers, php-fpm has an internal resource for this, pm.status_path - you can see what's in it with wget or any other http client:

[root@sol etc]# wget -O - -q http://localhost/status
pool:                 www
process manager:      dynamic
start time:           29/Jan/2015:11:36:20 +0300
start since:          1633615
accepted conn:        996160
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       34
active processes:     1
total processes:      35
max active processes: 18
max children reached: 0
slow requests:        0

It says that I have one active processes and one idle - thus I'm OK. The number of busy processes was 18 at it's maximum, thus I was OK all the time since the start.

Improve this answer
7
  • There are 2 times in the nginx log line: the first one is the one of the log message, while the second one is the one of the error detection event. You can notice that this second time and the time of the PHP worker recycling event match exactly. Workers are dimensioned accordingly as the load they are experiencing at the moment is nothing to compare to what thay can take, as they did before.
    – Bernard Rosset
    Feb 17, 2015 at 8:26
  • Yup, noted, thanks. But my answer still stands.
    – drookie
    Feb 17, 2015 at 8:31
  • It does and it has been accepted for its 'outdated version' part! Just out of curiosity: will 5.4.x branch be enough for an upgrade? Jumping from 5.3.x to v5.5.x sounds dangerous, even if (properly?) tested before landing in a production environment.
    – Bernard Rosset
    Feb 17, 2015 at 8:35
  • 5.4 will be enough (pay attention to call-time by reference being obsoleted), but the thing is, 5.4 is almost at the end of it's genesis, and soon you will need to switch to more recent version again. But yes, if it's too much at a time, you can switch to the latest 5.4.x.
    – drookie
    Feb 17, 2015 at 8:39
  • On the other hand your 'too few workers' part is less relevant since the discrepancy between times you mistakenly noticed does not exist. As said before, the load is very light on all the backends, compared to what it had already been able to take before. Definitely not a load problem.
    – Bernard Rosset
    Feb 17, 2015 at 8:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .