nginx スムーズ リスタートと FPM スムーズ リスタートとは何ですか?

スムーズ リスタート

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

nginx Smooth Restart

Nginx のプロセスはメインプロセスとワーカープロセスの 2 種類に分かれており、そのスムーズな再起動はシグナル HUB を通じて制御されます。

注: 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 の追加機能のほとんどを置き換えるために使用されます。 php5 FPM は .3.3 から統合されています。PHP-FPM は、./configure で –enable-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はそんなに低いのでしょうか?その時点での答えはノーでした。実際、私たちの目標は 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 は表示されなくなります。

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