Nginx プロセス管理とリロードの原則の詳細な説明

プロセス構造図

Nginx はマルチプロセス構造です。マルチプロセス構造は、次のような Nginx の高可用性と信頼性を確保するように設計されています。

マスタープロセス: ワーカープロセスの管理を担当する親プロセス
ワーカープロセス: 子プロセス。ワーカープロセスは通常、サーバーと同じ数の CPU コアで構成されます。ワーカープロセスは、特定のリクエストを処理するために使用されます。
キャッシュプロセス: キャッシュマネージャープロセスとキャッシュローダープロセスを含むサブプロセスでもあり、主にキャッシュのリバースプロキシとして使用されます。

注: マルチプロセスがマルチスレッドに比べて高可用性と高信頼性を保証できる理由は、プロセス間のアドレス空間が独立しており、プロセス間のタスクが互いに影響を及ぼさないためです。マルチスレッドと比較すると、CPU リソースをより多く消費します。複数のスレッドがプロセスのアドレス空間を共有するため、1 つのスレッドタスクの失敗は他のスレッドのタスクに影響します。

図3-1 Nginxプロセス構造図

Nginx サービスのユーザーが nginx であると仮定すると、次のコマンドを使用して、現在実行中の Nginx サービスのマスタープロセスとワーカープロセスを表示できます。また、4 つのワーカープロセスの親プロセス ID がマスターのプロセス ID (1325) であることがわかります。

[root@master ~]# ps -ef | grep nginx | grep -v grep | grep -v php-fpm
root 1325 1 0 11:28 ? 00:00:00 nginx: マスタープロセス /usr/local/nginx/sbin/nginx
nginx 1332 1325 0 11:28 ? 00:00:00 nginx: ワーカープロセス
nginx 1334 1325 0 11:28 ? 00:00:00 nginx: ワーカープロセス
nginx 1335 1325 0 11:28 ? 00:00:00 nginx: ワーカープロセス
nginx 1336 1325 0 11:28 ? 00:00:00 nginx: ワーカープロセス

図3-2 マスタープロセスと4つのワーカーサブプロセス

lsof -i:nginx端口號を通じてマスタープロセスとワーカープロセスを表示できます。

[ルート@マスター ~]# lsof -i:80
コマンド PID ユーザー FD タイプ デバイス サイズ/オフ ノード名
nginx 1325 ルート 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1332 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1334 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1335 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)
nginx 1336 nginx 6u IPv4 22282 0t0 TCP *:http (LISTEN)

セマフォ管理

Linux セマフォ管理メカニズム

シグナルは、プロセス間の通信方法の 1 つです。一般的な使用法としては、ターミナルユーザーがシグナルメカニズムを介して割り込みコマンドを入力し、プログラムの実行を停止します。

プロセスにシグナルを送信することで、プロセスを管理できます。kill kill -lコマンドを使用すると、Linux でサポートされているセマフォを表示できます。

Linux セマフォ

合計で 64 個のセマフォがあり、次のセマフォを明確にする必要があります。

kill -1 $PID: (SIGHUP) はプロセスを再ロードします。ターミナルから切断されたデーモンプロセスの場合、このシグナルは設定ファイルを再読み込みするように通知するために使用されます。

kill -2 $PID: (SIGINT) 割り込み (Ctrl+C 経由);

kill -3 $PID: (SIGQUIT) キーボード入力 (ctrl-\) を終了します。

kill -9 $PID: (SIGKILL) は、プログラムの現在の状態に関係なく、プロセスを直ちに終了します。

kill -10 $PID: (SIGUSR1) $USR1 と $USR2 はどちらもユーザー定義用に予約されたセマフォです。

-12 $PID:($IGUSR2) を強制終了します

kill -15 $PID: (SIGTERM) は通常プロセスを停止します。

kill -17 $PID: (SIGCHLD) 親プロセスと子プロセス間の通信のためのシグナル。親プロセスは、多くの子プロセスを fork() できます。子プロセスがハングアップすると、シグナルが親プロセスに送信されます。

kill は指定された情報をプログラムに送信できます。デフォルトのメッセージはSIGTERM(15)で、指定されたプログラムを終了します。それでも問題が解決しない場合は、SIGKILL(9) メッセージを使用してプログラムを強制的に削除してみてください。プログラムまたはジョブ番号は、ps コマンドまたは jobs コマンドを使用して表示できます。

kill -l # サポートされているすべての kill PID シグナルを表示します
# プロセスを強制終了する kill 1024
# 複数のプロセスを強制終了し、プロセス番号をスペースで区切ります kill 1024 2048
# kill -9 はプロセスを強制的に即時終了することを意味します kill -9 1024

注: Ctrl+C: ターミナルで実行中のプロセスを停止します。Ctrl+C は、ターミナルで実行中のプログラム (プロセス) を効果的に終了できます。

セマフォを使用してNginxプロセスを管理する

Nginxプロセスは、 master進程、 worker進程、命令行3つの方法で管理できます。

セマフォを使用してマスタープロセスとワーカープロセスを管理します (ワーカープロセスを管理するためにセマフォを使用することは推奨されません。ワーカープロセスはマスタープロセスによって管理および保守される必要があります)。

マスタープロセス

ワーカープロセスの監視

幼児

ワーカープロセスの管理

信号の受信

期間、INT
やめる
ＨＵＰ
USR1
USR2
ウインチ

例：

killコマンドを使用してマスタープロセスを強制終了します。

キル -s SIGTERM 1325

kill コマンドを使用して Nginx にファイルを再読み込みさせ、ワーカープロセスを閉じて新しいワーカープロセスを生成します。マスタープロセス (ID) は変更されません。

キル -s SIGHUP 1325

ワーカープロセス

信号の受信

期間、INT
やめる
USR1
ウインチ

セマフォを使用してワーカープロセスを直接管理することは可能ですが、推奨されません。ワーカープロセスは、マスタープロセスによって管理および保守される必要があります。

例：

ワーカープロセスを強制終了するには、kill コマンドを使用します。これにより、ワーカープロセスが強制終了されます。Linux は、強制終了されたワーカープロセスの親プロセス (マスタープロセス) に SIGCHLD シグナルを送信します。そのため、マスタープロセスは、子プロセスの 1 つに問題がある可能性があることを検出し、ワーカープロセスの数を維持するために新しいワーカープロセスを開始します。

キル -s SIGTERM 1332

コマンドライン

リロード:HUP
再開：USR2
停車駅：TERM
終了：終了

ヘルプコマンドを表示するにはnginx -hを使用します。

[itbsl@master ~]$ nginx -h
nginx バージョン: nginx/1.18.0
使用方法: nginx [-?hvVtTq] [-s シグナル] [-c ファイル名] [-p プレフィックス] [-g ディレクティブ]

オプション:
  -?,-h : このヘルプ
  -v : バージョンを表示して終了
  -V : バージョンと設定オプションを表示して終了する
  -t : 設定をテストして終了
  -T : 設定をテストし、ダンプして終了する
  -q : 構成テスト中にエラー以外のメッセージを抑制します
  -s シグナル: マスタープロセスにシグナルを送信: 停止、終了、再開、再ロード
  -p prefix : プレフィックスパスを設定します (デフォルト: /usr/local/nginx-1.18.0/)
  -c ファイル名: 設定ファイルを設定します (デフォルト: conf/nginx.conf)
  -g ディレクティブ: 設定ファイルからグローバルディレクティブを設定する

パラメータの説明:

-?,-h: ヘルプを表示
-v: Nginxのバージョンを確認する
-V: Nginx のバージョンとコンパイルオプションを表示します
-t: 設定ファイルの構文が正しいかどうかを確認します
-T: 設定ファイルの構文が正しいかどうかをチェックし、印刷します
-q: 設定ファイルのチェック時にエラー以外のメッセージを表示しない
-s: マスタープロセスに信号を送信します。送信できる信号は、stop、quit、reopen、reload です。
-c: 設定ファイルを指定する
-g: 設定ファイルの外でグローバルディレクティブを設定する

設定ファイルの再読み込みの原則

nginx マスタープロセスに SIGHUP シグナルを送信するか、 nginx -s reloadコマンドを使用して構成ファイルを再ロードすることで、nginx をスムーズにアップグレードできることがわかっています。では、このようなコマンドを実行した後、nginx 自体の舞台裏では何が起こるのでしょうか? 新しいリクエストと古いリクエスト間のスムーズな移行をどのように保証するのでしょうか?

設定ファイルのプロセスをリロードする

マスタープロセスにHUP信号を送信する（リロードコマンド）
マスタープロセスは構成構文が正しいかどうかをチェックします
マスタープロセスはリスニングポートを開きます（設定ファイル内のポートが変更されている場合は可能です）
マスタープロセスは新しい設定ファイルを使用して新しいワーカーサブプロセスを開始します。
マスタープロセスは古いワーカー子プロセスにQUITシグナルを送信します。
古いワーカープロセスは、現在の接続を処理した後、リスニングハンドルを閉じてプロセスを閉じます。

図を使って説明すると次のようになります。

nginx -s リロード

グラフィック分析:

1. 左側の緑色のステータスはnginx -s reloadコマンドを実行する前のステータスです。私の個人ホストの構成によると、マスタープロセスが 1 つ、ワーカーサブプロセスが 4 つあります。

2. nginx -s reloadコマンドを実行した後、リクエストを処理した後、元のワーカープロセスが強制終了されることをシミュレートするために、タスクを完了して応答するまでに長い時間がかかるインターフェイスをシミュレートします。はい、コード内で 15 秒間スリープします。つまり、このインターフェイスが応答するまでに 15 秒かかります。時間が長いほど、中間状態を観察するのに便利です。インターフェイスは reload コマンドを実行する前に要求されることに注意してください。

<?php
    睡眠(15);
    echo json_encode(['msg' => 'hello world']);die();

3. マスタープロセスがタスクをワーカーサブプロセスに渡して処理することは既にわかっています。現在タスクは 1 つしかないため、タスクを処理するワーカープロセスは 1 つだけです。

4. reload コマンドを実行すると、マスタープロセスは 4 つの新しいワーカープロセス (上の図の黄色のワーカープロセス) を作成し (構成によって異なります)、古いアイドルワーカープロセス (緑のワーカープロセス) をシャットダウンします。リクエストを処理している古いワーカープロセスはすぐにはシャットダウンされませんが、リクエストが処理された後にシャットダウンされます。

5. 最後に残った古いワーカープロセスは、タスクを完了した後にシャットダウンされます。残っているものはすべて、新しい nginx.conf 構成によって生成された新しいワーカープロセスです。以下の図を参照してください。シャットダウン中の古いワーカープロセスは、上記で 15 秒間スリープするタスクインターフェイスの処理を完了していないため、まだ表示されています。

要約する

Nginx プロセス管理とオーバーロードの原則に関するこの記事はこれで終わりです。Nginx プロセス管理とオーバーロードの原則の詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: