コアの機能

user www www;
worker_processes 2;

error_log /var/log/nginx-error.log info;

events {
    use kqueue;
    worker_connections 2048;
}

...

accept_mutex off;

もしaccept_mutex が有効であれば、workerプロセスは交互に新しい接続を受け付けるでしょう。そうでなければ、全てのworkerプロセスは新しい接続について通知を受けることになり、もし新しい接続の量が小さければ、幾つかのworkerプロセスは単にシステムリソースを浪費するだけかも知れません。

EPOLLEXCLUSIVE フラグ (1.11.3)をサポートするシステム上や、reuseportを使う場合は、accept_mutexを有効にする必要はありません。

バージョン 1.11.3 以前は、デフォルト値は onでした。

accept_mutex_delay 500ms;

もしaccept_mutexが有効であれば、他のworkerプロセスが新しい接続を受け付けている場合に、workerプロセスが新しい接続の受け付けを再開するまでの最大の期間を指定します。

daemon on;

nginxがデーモンになるべきかどうかを決定します。主に開発時に利用されます。

選択されたクライアント接続のデバッグログを有効にします。他の接続は、error_log ディレクティブで設定されたログレベルを利用するでしょう。デバッグされる接続は、IPv4 または IPv6 (1.3.0, 1.2.1) アドレスかネットワークで指定されます。接続もホスト名を使って指定されるかも知れません。UNIXドメインソケットを使った接続(1.3.0, 1.2.1)については、"unix:"パラメータによってデバッグログが有効になります。

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    ...
}

このディレクティブが動作するには、nginxは--with-debugを使ってビルドされる必要があります。"A debugging log"を見てください。

このディレクティブはデバッグのために使われます。

例えばworkingプロセスの再起動時のソケットのリークのような内部的なエラーが検知されると、debug_pointsを有効にすることでシステムデバッガーを使った更なる解析のために、コアファイル作成(abort)あるいはプロセスの停止 (stop)に繋がります。

env TZ;

デフォルトでは、nginxはTZ変数を除いて親プロセスから引き継いだ全ての環境変数を削除します。このディレクティブは引き継いだ変数の幾つかの保持、それらの値の変更、あるいは新しい環境変数の生成をすることができます。これらの変数は次のようになります:

• 実行可能ファイルのlive upgradeの間、継承する;
• ngx_http_perl_moduleモジュールによって使われる;
• workerプロセスによって使われるライブラリが初期化の時にのみ変数をチェックすることが普通なので、この方法でシステムライブラリを制御することは常に可能とは限らないこと心に留めておいてください。このディレクティブを使ってシステムライブラリが設定される前にうまくやります。この例外は、上で述べた実行可能ファイルのlive upgradeです。

TZ変数は明示的な設定なしに常に継承され、ngx_http_perl_moduleモジュールで利用可能です。

利用例:

env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;

NGINXの環境変数は内部的にnginxによって使われ、ユーザによって直接設定されるべきではありません。

error_log logs/error.log error;

ログを設定します。幾つかのログは同じ設定レベルに指定されるかも知れません(1.5.2)。main 設定レベルで、ファイルへの書き込みが明示的に定義されていない場合、デフォrつおのファイルが使われるでしょう。

最初のパラメータはログが格納されるファイルを定義します。特別な値stderr は標準エラーファイルを選択します。syslogへの記録は最初のパラメータに"syslog:"プリフィックスを指定することで設定することができます。循環メモリバッファへの記録は"memory:"プリフィックスとバッファsizeを指定することで可能で、一般的にデバッグのために使用されます(1.7.11)。

二つ目のパラメータはログのレベルを決定し、以下のいずれかの一つです: debug, info, notice, warn, error, crit, alert あるいは emerg. 上のログレベルは重大度が増加する順番でリストされます。あるログレベルを設定すると、指定されたログレベル以上の全てのメッセージが記録されるでしょう。例えば、デフォルトのレベルerrorは、error, crit, alertとemerg メッセージを記録するでしょう。パラメータが省略されると、error が使われます。

debugログが動作するには、nginxは--with-debugを使ってビルドされる必要があります。"A debugging log"を見てください。

ディレクティブはバージョン1.7.11からのstream レベル、およびバージョン1.9.0からのmailレベルで指定できるでしょう。

接続処理に影響するディレクティブが指定されている設定ファイルコンテキストを提供します。

他の file、あるいは指定された maskに一致するファイルを設定にインクルードします。インクルードされたファイルは構文的に正しいディレクティブとブロックから成る必要があります。

利用例:

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

動的なモジュールをロードします。

例:

load_module modules/ngx_mail_module.so;

lock_file logs/nginx.lock;

nginxは accept_mutexを実装するためのロッキングメカニズムと共有メモリへの順次アクセスを利用します。ほとんどのシステムでは、ロックは最小単位の操作を使って実装されており、このディレクティブは無視されます。その他のシステムでは、"lock file"メカニズムが使われます。このディレクティブはロックファイルの名前のためのプリフィックスを指定します。

master_process on;

workerプロセスが開始されたかどうか決定します。このディレクティブはnginxの開発者のためのものです。

multi_accept off;

もし multi_acceptが有効であれば、workerプロセスは一度に一つの新しい接続を受け付けるでしょう。そうでなければ、workerプロセスは同時に全ての新しい接続を受け付けるでしょう。

このディレクティブは、もしkqueue接続処理メソッドが使われた場合には無視されます。なぜならそれは受け付けを待っている全ての接続の数を報告するからです。

pcre_jit off;

正規表現のために、設定の解析の時間で知られている"just-in-time compilation" (PCRE JIT) の利用を有効または無効にします。

PCRE JIT は正規表現の処理を大幅に高速化することができます。

JITは--enable-jit configurationパラメータを使ってビルドされたバーン8.20からのPCREライブラリで利用可能です。PCREライブラリがnginxと一緒に (--with-pcre=)ビルドされた場合は、--with-pcre-jit設定パラメータによってJITサポートが有効になります。

pid logs/nginx.pid;

メインプロセスのプロセスIDを保持するfileを定義します。

ハードウェアSSLアクセラレータの名前を定義します。

thread_pool default threads=32 max_queue=65536;

ワーカープロセスのブロッキング無しにマルチスレッドのファイルの読み込みおよび送信のために使われるスレッドプールの名前とパラメータを定義します。

threadsパラメータはプール内のスレッドの数を定義します。

プール内の全てのスレッドがbusyな場合は、新しいタスクはキューの中で待つでしょう。max_queueパラメータはキュー内で待つことができるタスクの数を制限します。デフォルトでは、65536 までのタスクがキューの中で待つことができます。キューがあふれた場合は、タスクはエラーで終了します。

workerプロセスのタイマーの分解能を減らし、従ってgettimeofday()システムコールされる回数を減らします。デフォルトでは、カーネルイベントを受け取るたびにgettimeofday()が呼ばれます。分解能の削減により、gettimeofday()は指定されたintervalごとに一回だけ呼び出されます。

例:

timer_resolution 100ms;

intervalの内部的な実装は使用されるメソッドによって異なります:

• kqueueが使われた場合はEVFILT_TIMERフィルター;
• eventportが使われた場合はtimer_create()フォルター;
• そうでなければ、setitimer()</c>

user nobody nobody;

worker_aio_requests 32;

worker_connections 512;

worker_priority 0;

worker_processes 1;