nginx スムーズ リスタートと FPM スムーズ リスタートについて話しましょう

この記事では、スムーズな再起動について説明し、nginx のスムーズな再起動と FPM のスムーズな再起動について詳しく紹介します。

スムーズ リスタート

GR は、Graceful Restart (スムーズ リスタート) の略で、転送サービスが中断されないようにする方法です。プロトコルが再起動されるときのメカニズム。
GR メカニズムの核心は、デバイスがプロトコルを再起動すると、周囲のデバイスに通知して、一定期間内に安定したネイバー関係とデバイスへのルートを維持することができることです。プロトコルの再起動後、周辺デバイスは情報 (GR をサポートするルーティング/MPLS 関連プロトコルによって維持されるさまざまなトポロジ、ルーティング、およびセッション情報を含む) の同期を支援し、デバイスを再起動前の状態に最短時間で復元します。州。プロトコル再起動処理全体で経路のフラッピングやパケット転送経路の変更はなく、システム全体が中断することなくデータを転送できます。このプロセスはスムーズな再起動と呼ばれます。

nginx のスムーズな再起動

nginx のプロセスはマスター プロセスとワーカー プロセスに分かれており、nginx のスムーズな再起動は信号ハブ。

注: POSIX 準拠のプラットフォームでは、SIGUSR1 と SIGUSR2 は、ユーザー定義の状況を表すプロセスに送信されるシグナルです。

nginx のスムーズな再起動プロセスを詳細に分析するために、nginx プロセスの変化を監視し続けます。
Send HUP signal

kill -HUP `cat /home/git/nginx/logs/nginx.pid`

##観測を通じて、大まかなスムーズな再起動を分析できます。プロセスは:

1. マスターは新しい構成を使用して n-1 個のワーカーと新しいマスターをフォークアウトします#2. 新しいワーカーは新しいリクエストを処理し、古いワーカーは実行後に終了します##3。新しいマスターを使用してサービスを引き継ぐ際、マスターは設定をリロードします
4。マスターがロードされ構成された後、新しいマスターはワーカー作業モードに切り替わります
スムーズな再起動後、マスター プロセス番号変わりません。

nginx スムーズ アップグレード

HUP はスムーズな再起動、設定の読み込みなどにのみ使用されます。nginx のバージョンをスムーズにアップグレードしたい場合は、コンパイルされたバイナリ ファイルをリロードするには、USR2 シグナルの助けが必要です。

1. USR2 シグナルを送信します

kill -USR2 `cat /home/git/nginx/logs/nginx.pid`

##この時点で、新しいマスターとワーカーをフォークアウトする nginx プロセスを観察します。 nginx.pid の内容が変更され、nginx.pid.oldbin ファイルが古いマスター pid を記録するためにログ ディレクトリに生成されます。

2. 古いマスターと nginx ワーカーに WINCH シグナルを送信します。つまり、新しいリクエストの受信は停止しますが、すでに処理中のリクエストは終了しません。一定の時間が経過すると、古い nginx のすべてのワーカー プロセスが終了し、マスター プロセスのみが残り、すべてのユーザー リクエストは新しい nginx プロセスによって処理されます。

kill -WINCH `cat /home/git/nginx/logs/nginx.pid.oldbin`

3. 古いマスターに QUIT シグナルを送信すると、古い nginx プロセスが完全に終了し、スムーズなアップグレードが完了します。

kill -QUIT `cat /home/git/nginx/logs/nginx.pid.oldbin`

FPM Smooth Restart

FPM (FastCGI Process Manager) は、PHP FastCGI Most を置き換えるために使用されます。追加機能のうち、php5.3.3 からは FPM が統合されており、./configure で –enable-fpm パラメータを渡すことで PHP-FPM を有効にすることができます。 FPM のスムーズな再起動は USR2 信号によって制御される必要がありますが、それは nginx のスムーズな再起動プロセスとはまったく異なります。

kill -USR2 `cat /home/git/php/var/run/php-fpm.pid`

fpm プロセスの観察を続けると、FPM がスムーズに再起動することがわかります。新しいマスターと子を開始する前に、子プロセスが完全に終了するまで待つ必要があります。プロセスが終了し、古いマスターが終了します。

さらなる分析には strace を使用してください

マスターが、リクエストを処理している子プロセスを含むすべての子プロセスに終了するように通知していることがわかります。

この結論をさらに検証するには、サーバー側のスリープ スクリプトを作成します

<?php
exec("sleep 5");
echo &#39;done&#39;;

用浏览器请求这个地址，并在此期间平滑重启fpm，请求直接502了。
nginx错误日志：

[error] 29841#0: *1646 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "localhost"

php bug#60961，也有对fpm无法优雅的实现平滑重启的说明。
难道FPM这么low？答案当时是no，实际上通过 process_control_timeout 参数可以实现我们的目标。

process_control_timeout

 设置子进程接受主进程复用信号的超时时间。可用单位：s（秒），m（分），h（小时）或者 d（天）。默认单位：s（秒）。默认值：0（关闭）。

 原则上，php-fpm会选择空闲的fastcgi进程去处理请求，在处理之前，php-fpm会给fastcgi发送信号，用来让fastcgi进程准备好接受请求处理。但是fastcgi进程并不总是能够处理请求，也就是不能总是响应该信号（比如出现假死的情况），这时候就需要设定php-fpm留给fastcgi进程响应信号的时间，如果超时了，php-fpm会想其他办法（例如选择其他fastcgi进程），这个就是process_control_timeout参数的作用。

 这个参数缺省是 0，也就是不生效，修改为10，重新验证，502已经不会再出现。

 结论：缺省情况下，PHP-FPM 无法保证平滑的执行 reload 操作，必须设置一个合理的 process_control_timeout 才行，同时需要注意的是其值不能设置的过大，否则系统可能出现严重的请求堵塞问题。

推荐学习：《PHP视频教程》

以上がnginx スムーズ リスタートと FPM スムーズ リスタートについて話しましょうの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。