nginxのの深い理解：モジュールの開発とアーキテクチャを解析する（第二版）の注意事項を読んで

起源

nginxのとの接触は、（以下、ngの表記）のみ公開されていない、私がすることができていない、学ぶことがたくさんがありますが、実際には、早けれ著者NGとは2015年、ときに、プロジェクトで使用されてきたが、限られた知識に限られていました深い理解を行うためにngの。最近少し空のプロジェクトなので、タオ登輝の読み取りになる方法を知るために、より深い理解をngのやるために準備され、「nginxのの深い理解を：モジュールの開発とアーキテクチャを解析する（第二版）」、との記事も、この本を読んでノートにいくつかの利益を作ります。

オブジェクトについての記事を読む
この記事を読む前に、使用説明書をngのされていないこの記事では、一定の理解NGの基本的な使用にリーダーが必要ですので、この本を読む前に、私は、ngの、プロジェクトで使用されるngの一定の理解を持っています

設定について

自体は、我々は多くのモジュールを導入することができている容器、として理解することができるngの、いくつかのモジュールは、我々はそれを導入する必要がある場合ngの展開する必要があることが必要なのNGなどがあります。NGそこモジュールの数千人は、それぞれ独自の設定パラメータを持っています。この記事では、我々はいくつかのモジュールの構成を説明するために使用されます。

デバッグプロセスおよびオリエンテーションのための設定項目

（1）は、デーモンnginxののとして実行されている
構文：上のデーモン|オフ;
デフォルト：上のデーモン、
デーモン（デーモン）は、端末とバックグラウンドで実行中のプロセスのアウトです。これは、プロセスが端末によって生成された情報のいずれによっても中断されないように、任意の端末に表示された処理実行情報中の端末から逸脱することを避けるためです。nginxのは間違いなく、デーモンモードで実行するためのサービスのために必要であるので、デフォルトでは、このように実行することです。
gdbのプロセスをデバッグするときしかし、nginxのは、オファーがデーモンモードを閉じず、このモデルを提供するための理由は、nginxのをデバッグトレースを容易にするために、すべての後に、最も厄介は子プロセスのフォークをフォローアップを継続する方法です。これは便利であるとき、研究nginxのアーキテクチャの第三部。

（2）は、マスター/ワーカーモードで作業している
; |オフにmaster_process：構文
;上master_process：デフォルト
このすべてに、ほぼすべての本番環境の実行されている複数のワーカープロセスを管理するためのマスタープロセスを経由して、デフォルトのnginxの、nginxの作業の方法。
同じ構成デーモンはmaster_process設定を提供してトレースデバッグnginxのの便宜のためです。master_processの道閉鎖した場合、労働者はいないフォークの子プロセスの要求を処理するためにしますが、要求がマスター・プロセス自体によって処理されます。

セット（3）エラーログの
構文：error_logに/パス/ファイルレベル;
デフォルト：error_logのログ/ error.logにエラー、
エラーログがnginxの問題を見つけるための最良のツールである、我々は適切なパスエラーログを設定し、そのニーズに応じてすることができますレベル。
/パス/ファイルパラメータは、特定のファイルであってもよい、例えば、デフォルトのログ/ error.logにファイルである、それは十分なディスクスペースの場所を置くのがベストです。/パス/ファイルであってもよいの/ dev / nullにだから、出力任意のログをしませんが、これは、エラーログオフの唯一の手段であり、ログは標準エラー出力ファイルに出力されますので、/パス/ファイルは、標準エラー出力することができます。
レベルは、ログ出力レベルでのデバッグ、情報、告知、警告、範囲エラー、クリティカル、警告、EMERG、 レベルは左から右へ徐々に増加を。よりレベル以上に設定するかに/パス出力されるログ・レベルに等しいときに/ファイルのファイルは、より少ないレベルのログよりも出力されません。例えば、エラーレベルが設定されている場合、エラー、クリティカル、アラート、ログレベルは、出力EMERGあります。
ログレベルをデバッグに設定されている場合は、すべてのログが出力され、そのことは、大量のデータは、十分なディスクスペースがある前進/パス/ファイルディスクことを確認する必要があります。
なお、デバッグログレベルのセット場合は、ときのconfigure -with-デバッグの設定項目に参加する必要があります。

（4）いくつかの特定の点試運転のプロセスかどうか
構文：debug_points [ストップ|アボート]
この設定項目は、ヘルプのユーザーに使用されるがnginxのデバッグを追跡します。停止とアボート：それは2つのパラメータを受け付けます。いくつかの重要なミスロジックでnginxのは（nginxの1.0.14バージョンは8を持っている）デバッグポイントを設定します。debug_pointsが停止に設定されている場合、コードの実行nginxのSIGSTOPをデバッグするためにこれらの点をデバッグするための信号を送信します。debug_pointsを中止するように設定した場合、それはコアダンプファイルが生成されます、あなたは情報nginxの時間の多様性を見るためにGDBを使用することができます。
あなたは、通常、この設定項目を使用しません。

（5）のみ指定したクライアントの出力デバッグレベルのログの
構文：debug_connection [IP | CIDR]
この設定項目は、実際にイベントのクラス構成は、それゆえ、それはイベントに配置する必要があります{...}有効です属します。その値は、例えば、IPアドレスやCIDRアドレスであってもよい：
{イベント
; debug_connection 10.224.66.14
debug_connection 10.224.57.0/24;
}
このように、上記の要求からIPアドレスのみが出力デバッグレベルのロギング、他の要求が依然として使用されますのerror_log構成されたログレベル。
上記のこの構成のためのバグ修正、特に問題が発生します位置付ける高い同時リクエストで、便利です。
-with-デバッグのconfigureの実装で引数に参加したことを確認する必要があり、前にdebug_connectionの使用に注意してください、それが有効になりません。

（6）限界コアダンプコアダンプファイルサイズの
構文：worker_rlimit_coreサイズ、
システムは、ファイルを書き込むための処理を実行する場合、Linuxシステムでは、エラーが発生した場合、またはプロセスが終了したときに信号が受信され、メモリ内容（コアの画像） （コアファイル）、デバッグ目的として、これは、いわゆるコアダンプ（コア・ダンプ）です。オペレーティングシステムの強制閉鎖につながる（メモリ境界など）いくつかの不正な操作プロセスは直接、それがコアダンプコアファイルを生成nginxのプロセスは、私たちが問題を見つけ、スタック、レジスタ、文書やヘルプにコアから他の情報を一度に取得することができます。制限されていない場合でも、この文書に記載されている情報の多くは、必ずしもユーザーのコアのニーズではありません、そして、コア・ファイルは、そのわずか数コアダンプが深刻な問題を引き起こして、ディスクを記入します、いくつかのGBに達する可能性があります。あなたは効果的に、ヘルプのユーザーが問題を見つけworker_rlimit_core構成を介して、コアファイルのサイズを制限することができます。

（7）指定されたコアダンプファイル生成ディレクトリ
構文：working_directoryパス、
作業ディレクトリワーカープロセス。唯一の目的は、構成アイテムは、問題を見つける助けにコアダンプファイルディレクトリに置かれる設定することです。そのため、ワーカープロセスが書き込みファイルへworking_directory指定されたディレクトリへのアクセス権を持っていることを確認する必要があります。

設定項目の正常な動作

（1）環境変数を定義する
構文は：のenv VAR | VAR = VALUE
この設定オプションは、オペレーティング・システム上で直接設定された環境変数にユーザーを可能にします。例えば：

env TESTPATH=/tmp/;

（2）ファイル、他の構成に埋め込まれ
、含める/パス/ファイル：構文
CIは、そのパラメータは、絶対パスまたはに対する相対パス（いずれであってもよく、ファイルを他のnginx.conf現在のコンフィギュレーションファイルに埋め込むことができる含みますnginxの設定ディレクトリ、例えばディレクトリnginx.conf）、：

include mime.types;
include vhost/*.conf;

私たちは、パラメータの値が明示的にファイル名を指定することができます見ることができる、またはファイル名には、ワイルドカード*が含まれていますが、1缶は、複数のプロファイルを埋め込みます。

パス（3）PIDファイルの
構文：pidのパス/ファイル;
デフォルト：PIDログ/ nginx.pid、
マスター・プロセスIDがpidファイルストレージ・パスの保存。指定したパスが同じで、いつでも変更が、適切なターゲットにPIDファイルを作成してくださいNginxは許可することができます実行するときに、デフォルトのパラメータ「-pid・パス」を設定し、ファイルが直接nginxのかどうかに影響を実行することができます。

（4）ユーザとユーザグループ実行nginxのワーカープロセス
構文：ユーザ名[グループ名];
デフォルト：誰も誰もユーザー、
ユーザーがマスター・プロセスを設定するために使用されているが、起動しないワーカープロセスアウトフォークは、ユーザおよびユーザグループで実行されています。「ユーザーusername;」の設定、ユーザーグループ名とユーザ名。
コマンド実行時にユーザーの設定パラメータの場合パラメータは、ユーザーとユーザーグループを指定された-user =ユーザ名と-group =グループ名、nginx.confケース。

（5）nginxのワーカープロセスを指定するには、ハンドル記述子の最大数開くことができる
構文：worker_rlimit_nofile制限を、
プロセス作業者が開くことができるファイルハンドルの最大数を提供しました。

（6）は、信号キュー制限
構文：worker_rlimit_sigpending限界を、
キューサイズnginxのに送信された各ユーザ信号を提供しました。つまり、ユーザによって送られる信号の量が再び失われる、ユーザの信号キューがいっぱいになったとき、です。

設定項目のパフォーマンスを最適化

（1）nginxのワーカーの数は、処理
構文：数worker_processes;
デフォルト：1 worker_processes、
マスタ/ワーカー動作モード数、ワーカー・プロセスの定義です。
ワーカー・プロセスの数は、直接パフォーマンスに影響します。そして、ユーザは、我々が何をすべきワーカー・プロセスの数を設定しますか？これは、実際にビジネスニーズに関連しています。
各ワーカー・プロセスは、シングルスレッドのプロセスであり、彼らはさまざまな機能を実現するために、各モジュールを呼び出します。これらのモジュールは呼び出しが表示されないブロックを確認した場合は、その後、どのように多くのCPUコアを構成する必要がありますどのように多くのプロセスには、それが発生を阻止する呼び出すことが可能であれば逆に、あなたは少しより多くのワーカープロセスを設定する必要があります。
リソースファイルの静的ヘッドへのアクセスを要求する場合例えば、（され事業は、ローカルディスク上の静的リソースファイルを読み込むためのユーザー要求の数が多いと、サーバー上の小さなメモリにつながる可能性があり、その大半は、ディスクを読み取るために対処しなければならない場合ゆっくり）、むしろメモリ内のディスクキャッシュよりも、ディスクI / Oコールがライブ労働者が全体的なサービスのパフォーマンスにつながる、時間の少量を処理ブロックすることがあります。
マルチワーカープロセスは、マルチコアシステムのアーキテクチャを最大限に活用することができるが、CPUコアの数よりもワーカー・プロセスの数ならば、それは（Linuxはプリエンプティブカーネルである）との間のスイッチングによる消費プロセスを増加させるであろう。一般的に、ユーザは、ワーカープロセスを設定する必要があり、CPUコアの数に等しく、そして以下worker_cpu_affinityバインドCPUコアを使用するように構成されています。

（2）特定のCPUコアにnginxのワーカープロセスを結合
構文：worker_cpu_affinityのcpumask [cpumask ...]
なぜワーカープロセスのバインドにそれの特定のCPUコアに？複数のワーカー・プロセスが同じCPUを略奪している場合、それは同期の問題になり、ワーカープロセスが非常にビジーであることを前提としています。一方、各ワーカー・プロセスあれば、カーネルのスケジューリングポリシーに完全な同時性を達成するために、排他的なAのCPUです。
4つのCPUコアが存在する場合、例えば、以下のように行うことができます。

worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;

注：Linuxオペレーティングシステム用にのみ設定さworker_cpu_affinity。この機能を実現するためのLinuxオペレーティングシステムsched_setaffinity（）システムコール。

（3）SSLハードウェアアクセラレータの
構文：ssl_engineデバイス、
サーバーSSLハードウェアアクセラレーションデバイスに存在する場合、SSLプロトコルの処理速度を高速化するように構成することができます。ユーザーは機器があるかどうかを確認するためにSSLハードウェアアクセラレーションを提供するために、コマンドOpenSSLを使用することができます。

openssl engine -t

（4）システムコールの実行頻度はgettimeofday
構文：timer_resolution T;
デフォルトでは、各時間はカーネルが更新するカーネルクロックによって実装、gettimeofdayの回実行戻り値（例えば、ファイルディスクリプタ、選択、投票たkqueueなど）イベントを呼び出しキャッシュクロックでnginxの。中間カーネルモードメモリいったんユーザーの状態にコピーするため、早期のLinuxカーネルでは、gettimeofdayのは、実行コストは、小規模ではありません。あなたがコールにgettimeofdayの頻度を低減する必要があるときに使用timer_resolution構成することができます。たとえば、「timer_resolutionの100msのは、」100ミリ秒ごとに一度にgettimeofdayを呼び出す前に、少なくとも表しています。
しかし、現在のカーネルのほとんどでは、このようなのx86-64アーキテクチャとして、ちょうどvsyscallをのgettimeofdayだけで、データアクセス、共有メモリ・ページではなく、通常のシステムコールを行い、コストが大きくない、一般的にこの構成を使用しないでください。時間がより正確に、各ラインのログファイルを印刷したい場合はまた、あなたはそれを使用することができます。

（5）nginxのワーカーは、設定の優先順位を処理
構文：worker_priorityの素敵な;
デフォルト：worker_priority 0;
構成アイテムのニースの優先順位は、nginxのワーカープロセスを設定するために使用されます。
ではLinuxや他のUnixライクなオペレーティングシステムでは、多くのプロセスがレディ状態にあるとき、すべての優先順位に従った処理は、一つのプロセスの実行を選択するには、このカーネルを決定します。プロセスのCPUタイムスライス割り当てサイズも大きい（のプロセスの優先度、優先度の高い、タイムスライス処理割り当てに関連付けられている、例えば、デフォルト設定では、最小のタイムスライスは、5msの、最大スロットであります）が800ms。このように、優先度の高いプロセスがより多くのシステムリソースを占有します。
動的調整（現在は±5の調整）を一緒に静的優先度とカーネルプロセスに係る実装製ケースの優先順位を決定します。nice値は、それは-20〜+ 19の範囲であり、プロセスの静的優先順位であり、-20最高の優先順位であり、+ 19は、最も低い優先度です。ユーザーはnginxのは、より多くのシステムリソースを占有したい場合ので、あなたは、nice値より小さい数を設定できますが、カーネルプロセスよりも小さいnice値を（通常は-5）はお勧めしません。

Eventクラスの設定項目

ロックが開いて受け入れるかどうか（1）
| [オフに] accept_mutex：構文
; ON accept_mutext：デフォルト
accept_mutexはnginxの負荷分散ロック、第9章イベント処理フレームワークでロードバランシングを達成するためにどのようにnginxの本の意志の詳細です。ここでは、読者はこのロックは、今度は新しいクライアントとの確立されたTCP接続のシーケンスを複数のワーカープロセスを可能にaccept_mutex知っている必要があります。労働者を確立する接続数7/8プロセスが接続worker_connectionsコンフィギュレーションの最大数に達すると、それは非常にすべてのワーカープロセスのハンドル端部の上に顧客を達成するために、ワーカープロセスの試みは、新しいTCP接続を確立する可能性を低減しますできるだけ近い要求。
短くなりますTCP接続を確立するために時間がかかりので、あなたはそれを閉じるとロックが、デフォルトで有効になって受け入れますが、ワーカープロセス間の負荷が非常に不均一になり、それを閉じるために推奨されていません。

パス（2）ロックファイルの
構文：LOCK_FILEパス/ファイル;
デフォルト：LOCK_FILEログ/ nginx.lock;
ロックがLOCK_FILE完全に有効にならないように、閉じて受け入れるならば受け入れるロックは、このロックファイルが必要な場合があります。あなたはアトミックロックをサポートしていないシステムアーキテクチャおよびその他の要因は、nginxのを率いて操作し、コンパイラにロックし、原因を受け入れて有効にした場合、そのロックはそうLOCK_FILE指定し、ファイルロックで（セクション14.8.1は、ファイルロックの使用方法を紹介します）受け入れ達成されますロックファイルを有効にします。
I386に基づいて、AMD64、のSparc64は、オペレーティングシステムのPPC64アーキテクチャ、GCCの使用、インテルC ++、たsunpro Cの上にいることを注意 ++ nginxのは、CPUを使用しますので、nginxのをコンパイルするコンパイラ、あなたは、この時間nginxのサポートアトミックロックで確認することができます特性及び（基準アトミック操作部14.3 x86アーキテクチャで達成されてもよい）、アセンブリ言語で実装。この時間LOCK_FILE構成は無意味です。

（3）実際の接続との間の遅延時間を設定するロックの使用承諾
; accept_mutex_delay NMS：構文
デフォルト：accept_mutex_delayの500ミリ秒を、
ロックを受け入れる使用した後、同時に唯一のワーカープロセスがロックを受け入れるために取ることができます。すぐに返すために失敗した場合、このロックは、ロックをブロック受け付けていません。ある場合は、ワーカー・プロセスの試行はロックしますが、それはロックを取得するために再度試みる前に、少なくとも時間accept_mutex_delay定義された間隔を待つために取得するために取ることを許可しませんでした。

（4）バルク新たな接続を確立
構文：[ON | OFF] multi_acceptを;
デフォルト：multi_acceptオフ、
TCPは、このスケジューリングを要求したすべてのための新たな接続通知イベントモデルがある場合には、可能な限りの接続を確立するために、クライアントによって開始されています。

（5）選択したイベントモデルの
構文：使用[kqueueの| rtsig |ファイルディスクリプタ |は/ dev /世論調査|選択|世論調査| eventport];
デフォルト：nginxのは、自動的に最も適切なイベントモデルを使用します。
Linuxオペレーティングシステムでは、イベント駆動型モデルの選択は、世論調査、選択、ファイルディスクリプタ3を持っています。epollは、ファイルディスクリプタが大きいの同時接続を処理することができ、なぜ9.6は説明します、確かに最高のパフォーマンスの一つです。

各作業者の接続の最大数（6）
構文：worker_connections数、
各ワーカー・プロセスに対して定義された接続の最大数を同時に扱うことができます。