|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #77060 PHP-FPM pm.process_idle_timeout behaviour
Submitted: 2018-10-25 14:30 UTC Modified: 2018-11-04 17:12 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: contact at sshilko dot com Assigned: bukka (profile)
Status: Assigned Package: FPM related
PHP Version: 7.2.11 OS: Amazon Linux 2
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: contact at sshilko dot com
New email:
PHP Version: OS:


 [2018-10-25 14:30 UTC] contact at sshilko dot com
Hello, i manage multiple AWS EC2 servers, with docker running on them.
I compile and deploy php, and have deep knowledge of configuration options - to the level where i look up how things work in PHP source code.

My question/bug is that php-fpm fastcgi server configuration option
as seen

When set to low values doesnt make any difference: whether its 10 seconds or 1 second.

Typical scenario is i have 50 php-fpm child workers running, then with traffic spike the go up to >150 workers. But when traffic spike is over (after 10..50 seconds) the amount of workers remain between 150...140 for another 5-10 minutes, and basicly never goes down to previous level of 50.

process_idle_timeout states 
"The number of seconds after which an idle process will be killed. Used only when pm is set to ondemand"

Which is not true.

Even if server is able to serve requests with <50 workers, it keeps >100 running after spike is over.

Does that happen because it round-robin requests thru all those 150 workers and each of 150 workers get a request in less than 1 second ?

Because my setting is process_idle_timeout=1 

Test script:
Linux ip-172-30-0-201.ec2.internal 4.14.47-64.38.amzn2.x86_64 #1

PHP-FPM 7.2.11


user = www-data
group = www-data
listen = /var/run/php7-fpm.sock
listen.owner = www-data = www-data
pm.process_idle_timeout = 1;
;when pm=ondemand, backlog cant be lower than 511
listen.backlog = 511
pm = ondemand
pm.max_children = 150
pm.start_servers = 80
pm.min_spare_servers = 10
pm.max_spare_servers = 20

    fastcgi_index rawrpc.php;
    try_files $uri =404;
    include /etc/nginx/fastcgi_params;
    fastcgi_pass unix:/var/run/php7-fpm.sock;
    fastcgi_buffer_size 4k;
    fastcgi_buffering on;
    fastcgi_buffers 8 4k;
    fastcgi_cache nginxcache;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_cache_valid 200 5m;
    fastcgi_connect_timeout 15;
    fastcgi_keep_conn on;
    fastcgi_no_cache $skip_cache;
    fastcgi_read_timeout 90;
    fastcgi_request_buffering on;
    fastcgi_send_timeout 5;

    fastcgi_param SCRIPT_FILENAME $request_filename;


Expected result:
Setting process_idle_timeout=1 will terminate workers to previous level (before spike)

Actual result:
Setting process_idle_timeout=1 does not affect workers spawned amount at all, all the child processes spawned keep on going for few more hours.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2018-10-28 18:26 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: bukka
 [2018-10-28 18:26 UTC]
Well this option has got effect only if you have request running longer than process_idle_timeout seconds (in your case more than 1 second). Basically the timer is reset after returning response so the child won't get killed if it the request is short which is usually the case. It is meant just to kill the long running requests. Have you got such long running requests or are your requests quick?
 [2018-10-29 07:17 UTC] contact at sshilko dot com
My average 99% server (php-fpm) response times are within 30...100ms, measured by AWS ELB and NewRelic.

If it indeed only affects php-fpm childs that (return requests in > process_idle_timeout), then it may explain the behaviour seen.

Fix would be to have a different behaviour (scheduler/time measure) or allow <1second argument value, or update documentation at least.
 [2018-11-04 17:12 UTC]
-Status: Feedback +Status: Open -Type: Bug +Type: Documentation Problem
 [2018-11-04 17:12 UTC]
I agree that the docs should be a bit clearer so changing it to doc bug.

I think that to address your problem, we would need to have a smarter process manager that can properly scale in and out.
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Oct 19 03:03:34 2021 UTC