☰

PHP-FPM ondemand: Anzahl der aktiven untergeordneten Elemente bis max_children, danach funktioniert PHP nicht mehr

tag-icon • tag-icon nginx php-fpm
PHP-FPM ondemand: Anzahl der aktiven untergeordneten Elemente bis max_children, danach funktioniert PHP nicht mehr

Auf meinem Server laufen 10 Websites, sehr geringer Datenverkehr. Konfiguration:

  • Ubuntu 20.04.5 LTS
  • Nginx 1.18.0 (Ubuntu)
  • PHP 7.4.3

Innginx.confFolgendes wird hinzugefügt:

        upstream local_php {
                server unix:/run/php/php7.4-fpm.sock;
        }

InSites-fähigDie Konfigurationsdateien befinden sich unter anderem an folgenden Speicherorten:

        location ~ \.php$ {
                include fastcgi.conf;
                fastcgi_intercept_errors on;
                fastcgi_pass local_php;
                fastcgi_buffers 16 16k;
                fastcgi_buffer_size 32k;
        }

Mein/etc/php/7.4/fpm/pool.d/www.confhat:

pm = ondemand
pm.max_children = 15
pm.max_requests = 10

Was jetzt passiert, ist, dass meine Sites einwandfrei laufen, aber die PHP-Protokolldatei zeigt, dass die Anzahl der aktiven untergeordneten Elemente stetig zunimmt. Nach etwa einem Tag erreicht sie 15 und dann funktioniert PHP nicht mehr. Wenn man sich die Prozessliste ansieht, sieht man, dass es untergeordnete Elemente jeden „Alters“ gibt, die scheinbar ziellos weiterleben. Es gibt keine Warnungen in der PHP-Protokolldatei, nur diese, wenn Folgendes max_childrenerreicht wird:

WARNING: pid 75057, fpm_pctl_on_socket_accept(), line 518: [pool www] server reached max_children setting (15), consider raising it

Ich habe versucht, die PHP-Einstellungen zu optimieren. Mit pm = dynamicwerden max_children viel schneller erreicht. max_requestswar zunächst höher, aber das Herabsetzen hat keinen nennenswerten Unterschied gemacht. Ich habe genügend Ressourcen, um es max_childrenetwas zu erhöhen, aber das verschiebt das Problem nur, löst es aber nicht.

Beachten Sie, dass mein Server keine Auslastungsprobleme hat. Die Speichernutzung übersteigt nie 35 % und die CPU-Auslastung liegt konstant bei 5 %.

Irgendetwas muss ich falsch machen, denn ich nehme an, die Kinder müssten irgendwann getötet werden, oder nicht?Das PHP-Protokoll besagt, dass Kinder getötet werden, dies verringert jedoch ständig die Anzahl der Ersatzkinder, nicht einmal die der aktiven Kinder:

DEBUG: pid 232350, fpm_pctl_perform_idle_server_maintenance(), line 365: [pool www] currently 8 active children, 2 spare children
DEBUG: pid 232350, fpm_got_signal(), line 82: received SIGCHLD
DEBUG: pid 232350, fpm_event_loop(), line 435: event module triggered 1 events
DEBUG: pid 232350, fpm_children_bury(), line 261: [pool www] child 289966 has been killed by the process management after 12.069386 seconds from start
DEBUG: pid 232350, fpm_pctl_perform_idle_server_maintenance(), line 365: [pool www] currently 8 active children, 1 spare children
DEBUG: pid 232350, fpm_got_signal(), line 82: received SIGCHLD
DEBUG: pid 232350, fpm_event_loop(), line 435: event module triggered 1 events
DEBUG: pid 232350, fpm_children_bury(), line 261: [pool www] child 289969 has been killed by the process management after 12.665847 seconds from start
DEBUG: pid 232350, fpm_pctl_perform_idle_server_maintenance(), line 365: [pool www] currently 8 active children, 0 spare children

Typischer Ablauf bei einer Kinderzahl von bis zu 15:

1390 vps@vps9029:/etc/php/7.4/fpm/pool.d $ ps -elf|grep php
4 S root    15528   15439  0  80   0 -  2397 -      Dec20 pts/1 00:00:00 sudo tail -f php7.4-fpm.log
4 S root    15537   15528  0  80   0 -  1378 -      Dec20 pts/1 00:00:12 tail -f php7.4-fpm.log
4 S root    75057       1  0  80   0 - 59077 -      Dec21 ?     00:00:26 php-fpm: master process (/etc/php/7.4/fpm/php-fpm.conf)
5 S www-data   94817   75057  0  80   0 - 84357 -   Dec21 ?     00:00:00 php-fpm: pool www
5 S www-data  104885   75057  0  80   0 - 84302 -   Dec21 ?     00:00:00 php-fpm: pool www
5 S www-data  125566   75057  0  80   0 - 66282 -   Dec21 ?     00:00:01 php-fpm: pool www
5 S www-data  143879   75057  0  80   0 - 65617 -   02:47 ?     00:00:00 php-fpm: pool www
5 S www-data  149198   75057  0  80   0 - 84441 -   03:56 ?     00:00:00 php-fpm: pool www
5 S www-data  149632   75057  0  80   0 - 84582 -   04:02 ?     00:00:08 php-fpm: pool www
5 S www-data  152959   75057  0  80   0 - 84515 -   04:43 ?     00:00:01 php-fpm: pool www
5 S www-data  178687   75057  0  80   0 - 65673 -   09:53 ?     00:00:00 php-fpm: pool www
5 S www-data  182987   75057  0  80   0 - 84178 -   10:46 ?     00:00:00 php-fpm: pool www
5 S www-data  187712   75057  0  80   0 - 84178 -   11:44 ?     00:00:00 php-fpm: pool www
5 S www-data  187713   75057  0  80   0 - 84178 -   11:44 ?     00:00:00 php-fpm: pool www
5 S www-data  197529   75057  0  80   0 - 84386 -   13:59 ?     00:00:00 php-fpm: pool www
5 S www-data  210404   75057  0  80   0 - 65569 -   16:48 ?     00:00:00 php-fpm: pool www
5 S www-data  213858   75057  0  80   0 - 65633 -   17:29 ?     00:00:00 php-fpm: pool www
5 S www-data  214975   75057  0  80   0 - 85465 -   17:44 ?     00:00:00 php-fpm: pool www

Antwort1

Die Ursache sind langsame Anfragen von einer der installierten Sites.

Es gibt eine ganze Reihe von FPM/NGINX-Einstellungen, die das Leben von Kindprozessen steuern. Dies sind jetzt meine Einstellungen, und sie scheinen die Kinder unter Kontrolle zu bekommen:

In /etc/php/7.4/fpm/pool.d/www.conf:

pm = ondemand
pm.max_requests = 10
pm.max_children = 15
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
  • request_terminate_timeout_track_finished = ja

In /etc/php/7.4/fpm/php.ini:

max_execution_time = 30
default_socket_timeout = 60

In /etc/nginx/nginx.conf:

keepalive_timeout 55;
fastcgi_read_timeout 60;

verwandte Informationen