Bug #77060 [Com]: PHP-FPM pm.process_idle_timeout behaviour

Edit report at https://bugs.php.net/bug.php?id=77060&edit=1 ID: 77060 Comment by: contact at sshilko dot com Reported by: contact at sshilko dot com Summary: PHP-FPM pm.process_idle_timeout behaviour Status: Feedback Type: Bug Package: FPM related Operating System: Amazon Linux 2 PHP Version: 7.2.11 Assigned To: bukka Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2018-10-28 18:26:46] bukka@php.net 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-25 14:30:10] contact at sshilko dot com Description: ------------ 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 pm_process_idle_timeout as seen http://php.net/manual/en/install.fpm.configuration.php https://github.com/php/php-src/blob/1ad08256f349fa513157437abc4feb245cce03fc/sapi/fpm/fpm/fpm_process_ctl.c#L368 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 [global] process_control_timeout=10s process.max=210 process.priority=0 log_level=warning [www] user = www-data group = www-data listen = /var/run/php7-fpm.sock listen.owner = www-data listen.group = www-data pm.process_idle_timeout = 1; security.limit_extensions=.php ;when pm=ondemand, backlog cant be lower than 511 listen.backlog = 511 request_terminate_timeout=902s listen.allowed_clients=127.0.0.1 pm = ondemand pm.max_children = 150 pm.start_servers = 80 pm.min_spare_servers = 10 pm.max_spare_servers = 20 pm.max_requests=400 Nginx 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=77060&edit=1