worker_processes
worker_processes auto;
CPUコアの数に設定してくれる。
$ lscpu
...
CPU(s): 4
...
この場合workerプロセス数は4になる。
worker_connections
events {
worker_connections 8192;
}
一個のワーカープロセスによって同時に開くことができる接続数の最大値.
worker_connections
※注意
- 同時接続数はNginxが開けるファイル数の上限を超えることはできないことでそれはworker_rlimit_nofileで変更できる
- 必要であればOSが設定しているエフェメラルポートの数を調整する
エフェメラルポート
nginxが接続をはるとき、エフェメラルポートの数以上には接続できないのでOSで設定されている数を確認して必要であれば変更する。
確認方法
$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
エフェメラルポート
カーネルパラメータを調整して広げる
$ sudo sysctl -w net.ipv4.ip_local_port_range='1024 65535'
[sudo] password for watanata:
net.ipv4.ip_local_port_range = 1024 65535
$ sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 1024 65535
広げた。こうすると64,511くらいは使える。
リバースプロキシとして使うとき1コネクションあたりソケットを2つ使うらしい(検証の余地ありstackoverflow)ので、32000くらいというところから32768にした
workerの数は4だから
32768 / 4 = 8192
worker_connections 8192
worker_rlimit_nofile
worker_rlimit_nofile 16384;
workerプロセスが開くファイル数の上限。
worker_rlimit_nofile
※注意
Nginxはリバースプロキシとして使う場合リクエストの受付とupstreamへのリクエストで1接続につき2つのファイルを使用する。
8192 * 2 = 16384でFA?
いいえ、OSの上限を確認する必要があります。
file discriptor
OS全体でオープン可能なファイル数の上限
$ cat /proc/sys/fs/file-max
1590275
worker数は4つなので
16384 * 4 = 65,536
余裕でした
ここまでで
- エフェメラルポートの拡張
- エフェメラルポートの数から
worker_processesを決定 -
worker_processesの2倍以上の数をworker_rlimit_nofileに設定
しました。
その後...
検証環境でのボトルネックを確認したところ、今回はどうやらネットワークが詰まってるっぽい。
net.ipv4.tcp_tw_reuseを設定してみる
net.ipv4.tcp_tw_reuse
これはなに？
https://qiita.com/tmshn/items/b49f1b51bfc472968b30
TCP接続終了時の最後のTIME_WAITの終了を待たずにその接続を他の接続に再利用する
net.ipv4.tcp_tw_reuse
どう設定する？
$ sysctl net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_reuse = 0
$ sudo sysctl -w net.ipv4.tcp_tw_reuse=1
注意
カーネルパラメータを変更する場合は
/etc/sysctl.conf
を編集しておく
sudo vim /etc/sysctl.conf