nginxの設定ファイルの基本ディレクティブ(simple directives)に関して、本家サイトのリファレンスを元に説明します。
本章では、参考ドキュメントに記載したnginx-modules-reference.pdfファイルの「1.1 Core functionality」節をベースに記載します。
尚、2017年6月初旬時点で本家サイトのドキュメント、は1.11.10をベースにしており、本サイトも同バージョン以降を対象とします。
「1.1 Core functionality」に定義された基本ディレクティブの内worker_関係は以下になります。
基本ディレクティブのうち、まずはworkerプロセスに関係するディレクティブにいて、
本家サイトを和訳及び検証機で確認します。
英語に抵抗が無い方は直接以下のpdfファイルを確認して下さい。
workderプロセスの数を制限するworker_processesはnginxの特徴である１コアに対して
Httpリクエストを処理実行するworkerプロセスの数を決定するディレクティブです。
worker_processes 数値 | auto;LinuxにおけるCPUのコア数は、/proc/cpuinfoファイルに定義されています。
CPUのコア数確認(Linux)
$lscpu
rchitecture: i686
CPU 操作モード: 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
コアあたりのスレッド数:1
ソケットあたりのコア数:2
Socket(s): 1
ベンダー ID: GenuineIntel
CPU ファミリー: 6
モデル: 23
Model name: Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz
ステッピング: 6
CPU MHz: 800.000
CPU max MHz: 2101.0000
CPU min MHz: 800.0000
BogoMIPS: 4189.32
仮想化: VT-x
L1d キャッシュ: 32K
L1i キャッシュ: 32K
L2 キャッシュ: 3072K
または、「/proc/cpuinfo」ファイルをcatで確認することで、LinuxサーバのCPUが確認できます。
私の古いPCでは上記のように出力され、CPU(s)項目からコア数が2コアであることを示しています。
よって、私の古い検証用PCでのworker_processは2に設定します。
workerプロセス数の確認(サービスの場合)
$sudo systemctl status nginx
● nginx.service - The NGINX HTTP and reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: en
Active: active (running) since 木 2017-06-08 20:08:20 JST; 8min ago
Process: 2199 ExecStop=/bin/kill -s QUIT $MAINPID (code=exited, status=0/SUCCE
Process: 2230 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
Process: 2226 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
Main PID: 2232 (nginx)
CGroup: /system.slice/nginx.service
└2232 nginx: master process /usr/sbin/ngin
└2233 nginx: worker proces
└2234 nginx: worker proces
6月 08 20:08:20 yourserver systemd[1]: Starting The NGINX HTTP and reve
6月 08 20:08:20 yourserver nginx[2226]: nginx: the configuration file /
6月 08 20:08:20 yourserver nginx[2226]: nginx: configuration file /etc/
6月 08 20:08:20 yourserver systemd[1]: Started The NGINX HTTP and reve
workerプロセス数の確認(プロセスで確認)
$ps -aux | grep nginx
root 2289 0.0 0.0 7248 544 ? Ss 20:28 0:00 nginx: master process /usr/sbin/nginx
nginx 2290 0.0 0.1 7412 2500 ? S 20:28 0:00 nginx: worker process
nginx 2291 0.0 0.1 7412 2500 ? S 20:28 0:00 nginx: worker process
上記のように２行worker proces と表示され、２つのworkerプロセスが起動しました。
autoに変更した場合には、私の2コア(Core 2 Duo)の環境では、２つのworkerプロセスが起動しました。
サーバー設定時には、コア数とautoの両方の値を検証して下さい。
worker_cpu_affinity cpumask...;worker_cpu_affinity auto [cpumask]...;例えば
worker_cpu_affinityの設定例1
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
各workerプロセスを別のCPUにバインドします。
worker_cpu_affinityの設定例2
worker_processes 2;
worker_cpu_affinity 0101 1010;
第1のワーカープロセスをCPU0 / CPU2にバインドし、第2のワーカープロセスをCPU1 / CPU3にバインドします。
2番目の例は、ハイパースレッディングに適しています。
1.9.10からリリースされたworker_cpu_affinityの設定値autoは、workerプロえセスにCPUを自動に割り当てます。
worker_cpu_affinityの設定例3
worker_processes auto;
worker_cpu_affinity auto;
オプションのmaskパラメータを使用して、自動バインディングで使用可能なCPUを制限することができます。
worker_cpu_affinityの設定例4 使用可能なCPUを制限する例
worker_processes auto;
worker_cpu_affinity auto 01010101;
※.この設定４の方法は、LinuxとFreeBSDだけ利用可能です。
worker_priority 数値;worker_rlimit_core サイズ数値;RLIMIT_CODEとはコアダンプファイルサイズの上限を意味します。
以下の参考サイトの内容に関してコアダンプを確認して下さい。
workerプロセスがCPUの操作時の致命的なエラーが発生するとコアダンプファイルを出力するため、
このファイルが肥大化が起因としてトラブルを回避するための設定項目です。
Linuxのコアダンプの制限の状態を確認するコマンド
$ulimit
$unlimited
私の検証用PC(Ubuntu16.04LTS)では、未制限でした。
worker_rlimit_nofile 数値;RLIMIT_NOFILEは、プロセスが開くことができるファイルディスクリプタの上限値を決めます。
Linuxのファイルディスクリプタの上限値を確認します。
Linuxのファイルディスクリプタ上限の確認
$ulimit -n
1024
OS全体のファイルディスクリプタ上限の確認
$cat /proc/sys/fs/file-max
201103
nginxのログファイル(/var/log/nginx/error.log)に「Too many open files」が出力された時には、
前項で説明した「worker_rlimit_nofile」の値を超えてworkerプロセスがファイルを開く処理を実行しようとした結果、
ファイルディスクリプタの上限値を超えたためファイルの読み込みができなかった事を意味します。
error.logの出力内容
$tail /var/log/nginx/error.log
2017/06/09 16:05:33 [crit] 2288#2288: accept4() failed (24: Too many open files)
workerプロセスのファイルディスクリプタの上限値確認
$ ps aux | grep nginx
root 2339 0.0 0.0 7248 544 ? Ss 16:16 0:00 nginx: master process /usr/sbin/nginx
nginx 2340 0.0 0.0 7412 2004 ? S 16:16 0:00 nginx: worker process
nginx 2341 0.0 0.0 7412 2004 ? S 16:16 0:00 nginx: worker process
$cat /proc/2340/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 15743 15743 processes
Max open files 1024 1024 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 15743 15743 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
「Max open Files」(Ubuntu16.04LTS)項目の1024(Soft Limit)が最大値となっています。
Too many open filesエラーが発生した場合には、worker_processesで指定した値(workerプロセス数)×worker_rlimit_nofileが、
OSの上限数を超えないようにulimitコマンドでファイルディスクリプタ(Soft Limit)を調整します。
working_directory ディレクトリ;https://www.nginx.com/resources/admin-guide/debug/に記載されているように、
nginxの挙動がおかしい時にworking_directory設定を有効及びdebug系設定を有効にして、コアダンプを確認するときに利用するようです。
worker_aio_requests 数値;eventコンテキストに属するディレクティブのため、利用時には以下のようにeventコンテキスト内に設定します。
worker_aio_requests設定箇所
event {
worker_aio_requests 32;
worker_connections 1024;
}
worker_connections 数値;このworker_connectionsは、TCPコネクション数(http接続数)に該当します。
そのため、設定できる最大値は、OSのlocal portで許可されている範囲になります。
Linuxのlocal portを確認し、設定できる最大値を検討します。
Linuxのlocal port確認
$ cat /proc/sys/net/ipv4/ip_local_port_range
32768 60999
私の検証機Ubuntu16.04LTSでは上記のような値が表示されました。
すると60999-32768=28231個をエフェラルポートとして利用可能という事になります。
すると１つのworkerプロセスに割り当てる同時接続数のため、worker_processes×worker_connectionsが28231以内にする必要があります。
私のCPUのコア数が２つしか無い検証機では、worker_connectionsの最大値を8192として、512,1024の倍数で調整すれば良いと思います。
更に、このディレクティブは、worker_rlimit_nofileと関連しており、
worker_connectionsの設定値は、worker_rlimit_nofile以内の値で設定する必要があります。
※.worker_connectionsがworker_rlimit_nofileより大きな値を設定した場合は、nginx -t の確認で警告が出力されます。
大規模なシステムのサーバでは、worker_processと利用できるエフェラルポート数から計算し、
worker_connectionsに対して512又は1024の倍数で設定値を調整し、負荷試験で適切な値を設定するのが望ましいでしょう。
eventコンテキストに属するディレクティブのため、利用時には以下のようにeventコンテキスト内に設定します。
worker_connections設定箇所
event {
worker_aio_requests 32;
worker_connections 1024;
}