
私のサーバーは 10 個の Web サイトを実行していますが、トラフィックは非常に少ないです。構成:
- Ubuntu 20.04.5 LTS
- Nginx 1.18.0 (Ubuntu)
- PHP 7.4.3
でnginx.conf次のように追加されます:
upstream local_php {
server unix:/run/php/php7.4-fpm.sock;
}
でサイト対応設定ファイルの場所は次のとおりです。
location ~ \.php$ {
include fastcgi.conf;
fastcgi_intercept_errors on;
fastcgi_pass local_php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
}
私の/etc/php/7.4/fpm/pool.d/www.confもっている:
pm = ondemand
pm.max_children = 15
pm.max_requests = 10
何が起こっているかというと、サイトは正常に動作しているのに、PHP ログ ファイルにはアクティブな子プロセスの数が着実に増加していることが示されています。1 日かそこらで、15 に達し、PHP は動作を停止します。プロセス リストを見ると、目的もなく生きているように見える、あらゆる「年齢」の子プロセスがあります。PHP ログ ファイルには警告はなく、max_children
に達したときの次の警告のみが表示されます。
WARNING: pid 75057, fpm_pctl_on_socket_accept(), line 518: [pool www] server reached max_children setting (15), consider raising it
PHP 設定を微調整しようとしています。 を使用するとpm = dynamic
、max_children にかなり早く到達します。max_requests
は最初は高かったのですが、下げても大きな違いはありませんでした。 少し増やすだけの十分なリソースがありますmax_children
が、それでは問題を先送りするだけで、解決にはなりません。
私のサーバーには負荷の問題がないことに注意してください。メモリ使用量は 35% を超えることはなく、CPU は 5% で安定しています。
私は何か間違ったことをしているに違いない。なぜなら、子供たちはいつかは殺されるべきだと思うから。そうではないのか?PHP ログには、子プロセスが強制終了されていると表示されますが、アクティブな子プロセスの数だけでなく、予備の子プロセスの数が常に減少しています。
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
子が最大 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
答え1
原因は、インストールされているサイトの 1 つからのリクエストが遅いことです。
子プロセスの存続を制御する FPM/NGINX 設定は数多くあります。これらは現在の私の設定であり、子プロセスを制御できるようです。
で/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
- リクエスト終了タイムアウトトラック終了 = はい
で/etc/php/7.4/fpm/php.ini
:
max_execution_time = 30
default_socket_timeout = 60
で/etc/nginx/nginx.conf
:
keepalive_timeout 55;
fastcgi_read_timeout 60;