Since we upgraded from v2.6.3 to v2.6.4, we are experiencing some problems with our php-fpm backend
The problem is that the php-fpm process gets stuck in a "read" state (and not go back to "accept" state).
Eventually php's pm.max_children is reached and the entire server will be killed by ec2's health checker.
I've done some debugging with strace, but have not found a pattern, because the servers gets lots of traffic, but the problem only occurs every once in a while. (maybe once in a 1000 requests)
root@frontend:~# strace -p 39614
strace: Process 39614 attached
read(5,
root@frontend:~# nsenter -t 39614 --net lsof -n -p 39614 | grep 5u
php-fpm 39614 www-data 5u IPv6 287757 0t0 TCP 172.18.0.3:9000->172.18.0.4:44492 (ESTABLISHED)
172.18.0.3 = app_php_1.app_default
172.18.0.4 = app_caddy_1.app_default
Im afraid that #5367 might need to be revisited.
I've reverted back to v2.6.3 and the problem is gone.
Since we upgraded from v2.6.3 to v2.6.4, we are experiencing some problems with our php-fpm backend
The problem is that the php-fpm process gets stuck in a "read" state (and not go back to "accept" state).
Eventually php's pm.max_children is reached and the entire server will be killed by ec2's health checker.
I've done some debugging with strace, but have not found a pattern, because the servers gets lots of traffic, but the problem only occurs every once in a while. (maybe once in a 1000 requests)
Im afraid that #5367 might need to be revisited.
I've reverted back to v2.6.3 and the problem is gone.