コアの機能

設定例
ディレクティブ
設定例     accept_mutex_delay
     daemon
     debug_connection
     debug_points
     error_log
     env
     events
     include
     load_module
     lock_file
     master_process
     multi_accept
     pcre_jit
     pid
     ssl_engine
     thread_pool
     timer_resolution
     use
     user
     worker_aio_requests
     worker_connections
     worker_cpu_affinity
     worker_priority
     worker_processes
     worker_rlimit_core
     worker_rlimit_nofile
     working_directory

設定例

user www www;
worker_processes 2;

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

events {
    use kqueue;
    worker_connections 2048;
}

...

ディレクティブ

構文: accept_mutex on | off;
デフォルト:
accept_mutex off;
コンテキスト: events

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

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

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

構文: accept_mutex_delay time;
デフォルト:
accept_mutex_delay 500ms;
コンテキスト: events

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

構文: daemon on | off;
デフォルト:
daemon on;
コンテキスト: main

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

構文: debug_connection address | CIDR | unix:;
デフォルト: -
コンテキスト: events

選択されたクライアント接続のデバッグログを有効にします。他の接続は、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"を見てください。

構文: debug_points abort | stop;
デフォルト: -
コンテキスト: main

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

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

構文: error_log file [level];
デフォルト:
error_log logs/error.log error;
コンテキスト: main, http, mail, stream, server, location

ログを設定します。幾つかのログは同じレベルに指定されるかも知れません(1.5.2)

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

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

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

ディレクティブはバージョン1.7.11から stream レベル上で指定することができます。

ディレクティブはバージョン1.9.0から mailレベル上で指定することができます。

構文: env variable[=value];
デフォルト:
env TZ;
コンテキスト: main

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

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

利用例:

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

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

構文: events { ... }
デフォルト: -
コンテキスト: main

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

構文: include file | mask;
デフォルト: -
コンテキスト: any

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

利用例:

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

構文: load_module file;
デフォルト: -
コンテキスト: main

このディレクティブはバージョン1.9.11から導入されました。

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

例:

load_module modules/ngx_mail_module.so;

構文: lock_file file;
デフォルト:
lock_file logs/nginx.lock;
コンテキスト: main

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

構文: master_process on | off;
デフォルト:
master_process on;
コンテキスト: main

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

構文: multi_accept on | off;
デフォルト:
multi_accept off;
コンテキスト: events

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

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

構文: pcre_jit on | off;
デフォルト:
pcre_jit off;
コンテキスト: main

このディレクティブはバージョン1.1.12から導入されました。

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

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

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

構文: pid file;
デフォルト:
pid nginx.pid;
コンテキスト: main

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

構文: ssl_engine device;
デフォルト: -
コンテキスト: main

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

構文: thread_pool name threads=number [max_queue=number];
デフォルト:
thread_pool default threads=32 max_queue=65536;
コンテキスト: main

このディレクティブはバージョン1.7.11から導入されました。

ワーカープロセスのブロッキング無しにマルチスレッドのファイルの読み込みおよび送信のために、名前付きのスレッドプールを定義します。

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

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

構文: timer_resolution interval;
デフォルト: -
コンテキスト: main

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

例:

timer_resolution 100ms;

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

構文: use method;
デフォルト: -
コンテキスト: events

使用するconnection processing methodを指定します。nginxはデフォルトで最も効果的なメソッドを使用するため、通常は明示的に指定する必要はありません。

構文: user user [group];
デフォルト:
user nobody nobody;
コンテキスト: main

workerプロセスによって使用される usergroup 特権を定義します。groupが省略されると、userと同じ名前のグループが使われます。

構文: worker_aio_requests number;
デフォルト:
worker_aio_requests 32;
コンテキスト: events

このディレクティブはバージョン1.1.4と1.0.7から導入されました。

epoll接続処理メソッドと一緒にaioを使う場合、一つのworkerプロセスの顕著な非同期I/Oオペレーションの最大numberを設定します。

構文: worker_connections number;
デフォルト:
worker_connections 512;
コンテキスト: events

workerプロセスによって開かれる最大同時接続数を設定します。

この数字は、クライアントとの接続だけでなく、全ての接続(例えば、プロキシされたサーバの接続など)を含むことに注意が必要です。もう一つの考慮すべきことは、同時接続の実際の数はopen fileの最大数の現在の上限を超えることができないということです。これはworker_rlimit_nofileによって変更することができます。

構文: worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
デフォルト: -
コンテキスト: main

workerプロセスをCPUのセットに紐付けます。それぞれのCPUセットは許可されたCPUのビットマスクによって表現されます。それぞれのworkerプロセスのために定義された別個のセットがあるべきです。デフォルトでは、workerプロセスはどの特定のCPUとも紐付けられていません。

例えば:

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

それぞれのworkerプロセスを個々のCPUに紐付けます。

worker_processes    2;
worker_cpu_affinity 0101 1010;

最初のworkerプロセスをCPU0/CPU2に、二つ目のworkerプロセスをCPU1/CPU3に紐付けます。二つ目の例はハイパースレッディングに適しています。

特別な値 auto (1.9.10) はワーカープロセスを自動的に利用可能なCPUに紐付けることができます::

worker_processes auto;
worker_cpu_affinity auto;

任意のマスクパラメータを自動的な紐付けに利用可能なCPUの制限をするために使うことができます:

worker_cpu_affinity auto 01010101;

このディレクティブはFreeBSDとLinuxだけで利用可能です。

構文: worker_priority number;
デフォルト:
worker_priority 0;
コンテキスト: main

niceコマンドでされるのに似たworkerプロセスのスケジュールの優先度を定義します: 負のnumberは優先度が高いことを意味します。通常変更される範囲は-20から20です。

例:

worker_priority -10;

構文: worker_processes number | auto;
デフォルト:
worker_processes 1;
コンテキスト: main

workerプロセスの数を定義します。

最良の値はCPUコアの数、データを保持するハードディスクドライブの数、ロードのパターン(だけとは限りません)を含む多くの要素に因ります。迷った場合は、利用可能なCPUのコアの数を設定する事が手始めとして良いでしょう("auto"はそれを自動検出しようとするでしょう)。

autoパラメータはバージョン1.3.8と1.2.5からサポートされています。

構文: worker_rlimit_core size;
デフォルト: -
コンテキスト: main

workerプロセスのためのcoreファイルの最大サイズの制限(RLIMIT_CORE) を変更しますメインプロセスの再起動無しに制限を増やすために使われます。

構文: worker_rlimit_nofile number;
デフォルト: -
コンテキスト: main

workerプロセスのためのファイルオープンの最大数の制限(RLIMIT_NOFILE)を変更します。メインプロセスの再起動無しに制限を増やすために使われます。

構文: working_directory directory;
デフォルト: -
コンテキスト: main

workerプロセスのための現在のワーキングディレクトリを定義します。coreファイルを書く時に最初に使われます。その場合workerプロセスは指定されたディレクトリに書き込みの権限を持つ必要があります。

TOP
inserted by FC2 system