高同時実行シナリオにおける nginx 最適化の詳細な説明

日常の運用・保守作業では、nginx サービスが頻繁に使用され、nginx の高同時実行性によって生じるパフォーマンスのボトルネックが発生することがよくあります。今日は、nginxのパフォーマンス最適化の設定について簡単に整理します（あくまでも私の実体験に基づくものなので、間違っているところがあれば指摘してくださいね～）

1. ここでの最適化は主に nginx の設定の最適化を指します。一般的に、nginx 設定ファイルの最適化では以下の項目がより効果的です。

1) nginx プロセスの数は、CPU の数に応じて指定することをお勧めします。通常、CPU コアの数と同じか、その倍数になります。

ワーカープロセス数 8;

2) 各プロセスに CPU を割り当てます。上記の例では、8 つのプロセスが 8 つの CPU に割り当てられています。もちろん、もっと多く記述したり、1 つのプロセスを複数の CPU に割り当てることもできます。

ワーカーCPUアフィニティ 00000001 00000010 00000100 0000100000 001000000 01000000 10000000;

3) 次のコマンドは、nginx プロセスによって開かれるファイル記述子の最大数を参照します。理論値は、システム内の開いているファイルの最大数 (ulimit -n) を nginx プロセスの数で割った値になります。ただし、nginx はリクエストを均等に分散しないため、ulimit -n の値と一貫性を保つのが最適です。

ワーカー_rlimit_nofile 65535;

4) epoll I/Oモデルを使用して非同期イベントを効率的に処理する

epoll を使用します。

5) 各プロセスに許可される最大接続数。理論上、各 nginx サーバーの最大接続数は、worker_processes*worker_connections です。

ワーカー接続 65535;

6) HTTP 接続タイムアウト。デフォルトは 60 秒です。この機能は、クライアントからサーバーへの接続を設定された時間内に有効に保つためのもので、サーバーへの後続の要求があった場合に、接続の確立または再確立を回避します。このパラメータを大きくしすぎないように注意してください。そうしないと、多くの無効な http 接続が nginx 接続の数を占有し、最終的に nginx がクラッシュしてしまいます。

キープアライブタイムアウト60;

7) クライアント要求ヘッダーのバッファ サイズは、システムのページング サイズに応じて設定できます。通常、要求のヘッダー サイズは 1k を超えません。ただし、システムのページングは​​通常 1k より大きいため、ここではページング サイズに設定されます。ページング サイズは、getconf PAGESIZE コマンドを使用して取得できます。

クライアント_ヘッダー_バッファ_サイズ 4k;

8) 次のパラメータは、開いているファイルのキャッシュを指定します。デフォルトでは有効になっていません。max はキャッシュの数を指定します。これは開いているファイルの数と一致するようにすることをお勧めします。inactive は、ファイルが要求されない場合にキャッシュが削除されるまでの時間を指します。

open_file_cache 最大=102400 非アクティブ=20秒;

9) 以下は、有効なキャッシュ情報を確認する頻度を示します。

open_file_cache_valid 30秒;

10) open_file_cache ディレクティブの非アクティブ パラメータ時間内にファイルが使用される最小回数。この数を超えると、ファイル記述子は常にキャッシュ内で開かれます。上記の例のように、非アクティブ時間内にファイルが一度も使用されない場合は、そのファイルは削除されます。

オープンファイルキャッシュの最小使用数は 1 です。

11) 応答ヘッダー内のオペレーティング システムと Web サーバー (Nginx) のバージョン番号に関する情報を非表示にします。これはセキュリティ上有効です。

server_tokens オフ;

12) sendfile() が動作できるようにします。 sendfile() は、ディスクと TCP ソケット間でデータ (または任意の 2 つのファイル記述子) をコピーできます。 Pre-sendfile は、データを送信する前にユーザー空間にデータ バッファーを適用します。次に、read() を使用してファイルからこのバッファにデータをコピーし、write() を使用してバッファ データをネットワークに書き込みます。 sendfile() はディスクからデータをすぐに OS キャッシュに読み取ります。コピーはカーネル内で行われるため、sendfile() は read() と write() を組み合わせて破棄バッファリングをオン/オフにするよりも効率的です (sendfile については後ほど詳しく説明します)。

ファイル送信オン;

13) ヘッダーを 1 つずつ送信するのではなく、すべてのヘッダーを 1 つのパケットで送信するように nginx に指示します。つまり、データ パケットはすぐには送信されません。データ パケットが最大になったときに、一度に送信されます。これにより、ネットワークの輻輳が解消されます。

tcp_nopush オン;

14) nginx にデータをキャッシュせず、少しずつ送信するように指示します。タイムリーにデータを送信する必要がある場合は、アプリケーションにこの属性を設定する必要があります。これにより、小さなデータ情報を送信するときに、戻り値がすぐに取得されなくなります。

tcp_nodelay オン;

例えば：

http { 
server_tokens オフ; 
ファイル送信オン; 
tcp_nopush オン; 
tcp_nodelay オン; 
......
} 

15) クライアント要求ヘッダーのバッファサイズは、システムページングサイズに応じて設定できます。通常、要求ヘッダーのサイズは 1k を超えません。ただし、システムページングは​​通常 1k より大きいため、ここではページングサイズに設定されます。

クライアント_ヘッダー_バッファ_サイズ 4k;

クライアント要求ヘッダーのバッファサイズは、システムページングサイズに応じて設定できます。通常、要求ヘッダーのサイズは 1k を超えることはありません。ただし、システムページングは​​通常 1k より大きいため、ここではページングサイズに設定されます。
ページング サイズは、getconf PAGESIZE コマンドを使用して取得できます。

[root@test-huanqu ~]# getconf ページサイズ 
4096

ただし、client_header_buffer_size が 4k を超える場合があります。ただし、client_header_buffer_size の値は、「システム ページング サイズ」の整数倍に設定する必要があります。

16) 開いているファイルのキャッシュを指定します。デフォルトでは有効になっていません。max はキャッシュの数を指定します。開いているファイルの数と一致させることをお勧めします。inactive は、ファイルが要求されない場合にキャッシュが削除されるまでの時間を指します。

open_file_cache 最大=65535 非アクティブ=60秒;

17) open_file_cache ディレクティブの非アクティブ パラメータ時間内にファイルが使用される最小回数。この数を超えると、ファイル記述子は常にキャッシュ内で開かれます。上記の例のように、非アクティブ時間内にファイルが一度も使用されない場合は、そのファイルは削除されます。

オープンファイルキャッシュの最小使用数は 1 です。

18) キャッシュされた情報の有効性をチェックする頻度を指定します。

open_file_cache_valid 80秒;

以下は私が使用するシンプルな nginx 構成ファイルです。

[root@dev-huanqiu ~]# cat /usr/local/nginx/conf/nginx.conf
ユーザー www www;
ワーカープロセス数 8;
ワーカーCPUアフィニティ 00000001 00000010 00000100 000010000 001000000 001000000;
error_log /www/log/nginx_error.log クリット;
pid /usr/local/nginx/nginx.pid;
ワーカー_rlimit_nofile 65535;
 
イベント
{
  epoll を使用します。
  ワーカー接続 65535;
}
 
http
{
  mime.types を含めます。
  デフォルトタイプ アプリケーション/オクテットストリーム;
 
  文字セット utf-8;
 
  サーバー名ハッシュバケットサイズ 128;
  クライアント_ヘッダー_バッファ_サイズ 2k;
  ラージクライアントヘッダーバッファ 4 4k;
  クライアントの最大ボディサイズは8mです。
 
  ファイル送信オン;
  tcp_nopush オン;
 
  キープアライブタイムアウト60;
 
  fastcgi_cache_path /usr/local/nginx/fastcgi_cache レベル=1:2
         keys_zone=テスト:10m
         非アクティブ=5分;
  fastcgi_connect_timeout 300;
  fastcgi_send_timeout 300;
  fastcgi_read_timeout 300;
  fastcgi_buffer_size 16k;
  fastcgi_buffers 16 16k;
  fastcgi_busy_buffers_size 16k;
  fastcgi_temp_file_write_size 16k;
  fastcgi_cache テスト;
  fastcgi_cache_valid 200 302 1時間;
  fastcgi_cache_valid 301 1d;
  fastcgi_cache_valid 任意の 1m;
  fastcgi_cache_min_uses 1;
  fastcgi_cache_use_stale エラー タイムアウト invalid_header http_500; 
  open_file_cache 最大=204800 非アクティブ=20秒;
  オープンファイルキャッシュの最小使用数は 1 です。
  open_file_cache_valid 30秒; 
 
  tcp_nodelay オン;
  
  gzip オン;
  gzip_min_length 1k;
  gzip_バッファ 4 16k;
  gzip_http_バージョン1.0;
  gzip_comp_レベル2;
  gzip_types テキスト/プレーン アプリケーション/x-javascript テキスト/css アプリケーション/xml;
  gzip_vary オン;
 
  サーバ
  {
   8080を聴く;
   サーバー名 huan.wangshibo.com;
   インデックス index.php index.htm;
   ルート /www/html/;
 
   場所 / ステータス
   {
     stub_status オン;
   }
 
   場所 ~ .*\.(php|php5)?$
   {
     127.0.0.1:9000; をデフォルトとして設定します。
     fastcgi_index インデックス.php;
     fcgi.conf をインクルードします。
   }
 
   場所 ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
   {
    有効期限は30日です。
   }
 
   log_format アクセス '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" $http_x_forwarded_for';
   access_log /www/log/access.log アクセス;
    }
}

2. FastCGIに関するいくつかの指示

1) このディレクティブは、FastCGI キャッシュのパス、ディレクトリ構造レベル、キー領域の保存時間、および非アクティブ削除時間を指定します。

fastcgi_cache_path /usr/local/nginx/fastcgi_cache レベル=1:2 キー_ゾーン=TEST:10m 非アクティブ=5m;

2) バックエンド FastCGI への接続のタイムアウトを指定します。

fastcgi_connect_timeout 300;

3) FastCGI にリクエストを送信するためのタイムアウト。この値は、2 つのハンドシェイクが完了した後に FastCGI にリクエストを送信する際のタイムアウトを示します。

fastcgi_send_timeout 300;

4) FastCGI 応答を受信するためのタイムアウト。この値は、2 つのハンドシェイクを完了した後、FastCGI 応答を受信するためのタイムアウトを示します。

fastcgi_read_timeout 300;

5) FastCGI 応答の最初の部分を読み取るために必要なバッファのサイズを指定します。ここでは、fastcgi_buffers ディレクティブで指定されたバッファ サイズに設定できます。上記のディレクティブは、応答の最初の部分、つまり応答ヘッダーを読み取るために 16k バッファを使用することを指定します。実際、この応答ヘッダーは一般に非常に小さい (1k 以下) ですが、fastcgi_buffers ディレクティブでバッファ サイズを指定すると、fastcgi_buffers で指定されたバッファ サイズもキャッシュに割り当てられます。

fastcgi_buffer_size 16k;

6）上記のページサイズが256kの場合、256kを超える場合、16kのバッファーが256kを超える場合、fastcgi_tempを使用したパスのパスでcashed in coss for for for chuse for chuse for chuse for chuse for for for for for for for for for for for for for for for for for for for for for for for for for for for sech ofs ecsid for spertにある場合は、FastCGIの応答の数と大きさを指定します。通常、この値は、サイト内のほとんどのスクリプトによって生成されたページサイズが256kである場合、ページサイズによって生成されたページサイズの中間値に設定します。 64 4Kを使用すると、8個の4Kバッファーがキャッシュに割り当てられ、16 16Kを使用すると、ページをキャッシュするために2 16Kを割り当てます。

fastcgi_buffers 16 16k;

7) このディレクティブが何に使用されるのかはわかりませんが、デフォルト値が fastcgi_buffers の 2 倍であることだけはわかっています。

fastcgi_busy_buffers_size 32k;

8) fastcgi_temp_path に書き込むときのデータ ブロックの大きさ。デフォルト値は fastcgi_buffers の 2 倍です。

fastcgi_temp_file_write_size 32k;

9) FastCGI キャッシュを有効にし、名前を割り当てます。個人的には、キャッシュを有効にすると、CPU 負荷を効果的に軽減し、502 エラーを防ぐことができるため、非常に便利だと感じています。しかし、このキャッシュは動的なページをキャッシュするため、多くの問題を引き起こす可能性があります。具体的な使用方法はニーズによって異なります。

fastcgi_cache テスト

10) 特定の応答コードのキャッシュ時間を指定します。たとえば、上記の例では、200 および 302 の応答は 1 時間キャッシュされ、301 の応答は 1 日間キャッシュされ、その他は 1 分間キャッシュされます。

fastcgi_cache_valid 200 302 1時間;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid 任意の 1m;

11) fastcgi_cache_path ディレクティブの非アクティブ パラメータ値の時間内にキャッシュが使用される最小回数。たとえば、ファイルが 5 分以内に 1 回も使用されない場合、そのファイルは削除されます。

fastcgi_cache_min_uses 1;

12) このパラメータの機能はわかりませんが、どのタイプのキャッシュが役に立たないかを nginx に知らせる必要があると思います。

fastcgi_cache_use_stale エラー タイムアウト invalid_header http_500;

上記は、nginx の FastCGI 関連のパラメータです。

また、FastCGI 自体にも最適化が必要な設定がいくつかあります。php-fpm を使用して FastCGI を管理する場合は、設定ファイルで次の値を変更できます。

1) 同時に処理される同時リクエストの数。つまり、同時接続を処理するために最大 60 個の子スレッドが開かれます。

<値名="max_children">60</値>

2) 開いているファイルの最大数。

<値名="rlimit_files">65535</値>

3) 各プロセスがリセットされる前に実行できるリクエストの最大数。

<値名="最大リクエスト数">65535</値>

3. /etc/sysctl.confファイル内のカーネルパラメータの最適化

1) 待機時間の数。デフォルトは 180000 です。 (Deven: したがって、timewait を短縮したい場合は、tcp_max_tw_buckets の値を減らす必要があります)

ネット.ipv4.tcp_max_tw_buckets = 6000

2) システムが開くことが許可されているポートの範囲。

net.ipv4.ip_local_port_range = 1024 65000

3) TIME-WAIT 状態のソケットの高速リサイクル機能を有効にします。これは、TIME-WAIT 状態の TCP 接続の数を迅速に削減するために使用されます。 1 は有効、0 は無効を意味します。ただし、このオプションを有効にすると、NAT (ネットワーク アドレス変換) ネットワークで多数の TCP 接続確立エラーが発生し、Web サイトへのアクセスが失敗するため、通常は推奨されません。

ネット.ipv4.tcp_tw_recycle = 0

実際、net.ipv4.tcp_timestamps スイッチを有効にした後、net.ipv4.tcp_tw_recycle 関数を有効にする必要があります (通常、システムはデフォルトでこの機能を有効にします)。

tcp_tw_recycle がオンになっている場合 (tcp_timestamps も同時にオンになっていると、高速ソケットリサイクルの効果が得られます)、NAT デバイスの背後にあるクライアントにとっては大惨事になります。

これにより、NAT デバイスの背後にあるサーバーへのクライアント接続が不安定になります (一部のクライアントはサーバーに接続できますが、一部のクライアントはサーバーに接続できません)。
つまり、tcp_tw_recycle 関数は、NAT が存在しない内部ネットワーク (ネットワーク環境が自己制御可能) 用に設計されており、パブリック ネットワークでの使用には適していません。

一般的に言えば、TIME_WAIT 状態のソケットをリサイクルする理由は、使用可能なポートがないため「リモート エンドにアクティブに接続できない」ためであり、メモリをリサイクルする (これは不必要) ためではありません。

つまり、要求はクライアントの要求であり、サーバーには「ポート不足」の問題が発生するのでしょうか?

フロントエンドマシンでない限り、バックエンドサービスへの多くの接続が必要であり、つまりクライアントの役割を果たします。

この問題の正しい解決策は常に次のようになります。

net.ipv4.ip_local_port_range = 9000 6553 #デフォルト値は小さいです net.ipv4.tcp_max_tw_buckets = 10000 #デフォルト値は小さいので、適宜調整できます net.ipv4.tcp_tw_reuse = 1 
ネット.ipv4.tcp_fin_timeout = 10

4) 再利用機能を有効にして、TIME-WAIT 状態のソケットを新しい TCP 接続に再利用できるようにします。この機能を有効にしても安全なので、通常は変更しないでください。

ネット.ipv4.tcp_tw_reuse = 1

5) SYN Cookie を有効にします。SYN 待機キューがオーバーフローした場合は、Cookie を有効にして処理します。

ネット.ipv4.tcp_syncookies = 1

6) Web アプリケーションの listen 関数のバックログにより、カーネル パラメータ net.core.somaxconn がデフォルトで 128 に制限されます。また、nginx で定義されている NGX_LISTEN_BACKLOG のデフォルト値は 511 であるため、この値を調整する必要があります。

ネット.コア.somaxconn = 262144

7) 各ネットワーク インターフェイスがパケットを受信する速度がカーネルがパケットを処理できる速度よりも速い場合に、キューに送信できるパケットの最大数。
ネット.コア.ネットdev_max_backlog = 262144

8) システム内で、どのユーザー ファイル ハンドルにも関連付けられていない TCP ソケットの最大数はいくつですか?この数を超えると、孤立した接続は直ちにリセットされ、警告メッセージが出力されます。この制限は単純な DoS 攻撃を防ぐためだけのものです。この制限に頼りすぎたり、この値を人為的に減らしたりしないでください。代わりに、この値を増やす必要があります (メモリを増やす場合)。

ネット.ipv4.tcp_max_orphans = 262144

9) クライアントの確認応答をまだ受信していない接続要求の最大記録数。 128M のメモリを搭載したシステムの場合、デフォルト値は 1024 であり、メモリが少ないシステムの場合、デフォルト値は 128 です。

ネット.ipv4.tcp_max_syn_backlog = 262144

10) タイムスタンプにより、シーケンス番号のラップアラウンドを回避できます。 1Gbps リンクでは、以前に使用されたシーケンス番号が必ず発生します。タイムスタンプにより、カーネルはそのような「異常な」パケットを受け入れることができます。

net.ipv4.tcp_timestamps = 1

パフォーマンスを向上させるために、多くのサーバーでは net.ipv4.tcp_tw_recycle オプションが有効になっています。NAT ネットワーク環境では、これにより Web サイトへのアクセス時に接続エラーが発生する可能性があります。

個人的なアドバイス:

net.ipv4.tcp_timestamps の代わりに net.ipv4.tcp_tw_recycle オプションをオフにします。

net.ipv4.tcp_timestamps がオフになっていると、net.ipv4.tcp_tw_recycle をオンにしても機能しません。ただし、net.ipv4.tcp_timestamps は独立してオンにして機能させることができます。

11) 相手側への接続を開くには、カーネルは前の SYN に応答して SYN と ACK を送信する必要があります。これは、いわゆる 3 ウェイ ハンドシェイクにおける 2 回目のハンドシェイクです。この設定は、接続を放棄する前にカーネルが送信する SYN+ACK パケットの数を決定します。

ネット.ipv4.tcp_synack_retries = 1

12) カーネルが接続の確立を諦める前に送信される SYN パケットの数。

ネット.ipv4.tcp_syn_retries = 1

13) ソケットがローカル側で閉じられた場合、このパラメータによって FIN-WAIT-2 状態が続く時間が決まります。ピアがミスを犯して接続を閉じなかったり、予期せずクラッシュしたりする可能性があります。デフォルト値は 60 秒です。 2.2 カーネルの通常の値は 180 秒です。この値を設定することはできますが、マシンが低負荷の Web サーバーであっても、多数のデッド ソケットが原因でメモリ オーバーフローが発生するリスクがあることに注意してください。FIN-WAIT-2 は、消費するメモリが最大 1.5K であるため、FIN-WAIT-1 よりも危険性は低くなりますが、有効期間は長くなります。

ネット.ipv4.tcp_fin_timeout = 30

14) キープアライブが有効な場合、TCP がキープアライブ メッセージを送信する頻度。デフォルトは 2 時間です。

ネット.ipv4.tcp_keepalive_time = 30

以下は私がよく使用するカーネルパラメータの標準設定です。

[root@dev-huanqu ~]# cat /etc/sysctl.conf
ネット.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
カーネル.sysrq = 0
カーネル.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1 //赤でマークされたこれらの4行は、通常、多数のTIME_WAITが見つかった場合の解決策です kernel.msgmnb = 65536
カーネル.msgmax = 65536
カーネル.shmmax = 68719476736
カーネル.shmall = 4294967296
ネット.ipv4.tcp_max_tw_buckets = 6000
ネット.ipv4.tcp_sack = 1
net.ipv4.tcp_window_scaling = 1
ネット.ipv4.tcp_rmem = 4096 87380 4194304
ネット.ipv4.tcp_wmem = 4096 16384 4194304
ネットコアwmem_default = 8388608
ネットコアrmem_default = 8388608
ネットコアrmem_max = 16777216
ネットコアのwmem_max = 16777216
ネット.コア.ネットdev_max_backlog = 262144
ネット.コア.somaxconn = 262144
ネット.ipv4.tcp_max_orphans = 3276800
ネット.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 1 //net.ipv4.tcp_tw_recycle が 1 に設定されている場合、このオプションは net.ipv4.tcp_synack_retries = 1 と組み合わせるのが最適です。
ネット.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1 // この機能を有効にすると、TIME-WAIT 状態を減らすことができますが、NAT ネットワーク モードでは TCP 接続エラーが発生する可能性があるので注意してください。
ネット.ipv4.tcp_tw_reuse = 1
ネット.ipv4.tcp_mem = 94500000 915000000 927000000
ネット.ipv4.tcp_fin_timeout = 30
ネット.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1024 65000
ネット.ipv4.ip_conntrack_max = 6553500

-------------------------------------小さな事故の記録----------------------------------------------------

net.ipv4.tcp_tw_recycle = 1 この機能をオンにすると、確かに TIME-WAIT 状態を減らすことができます。私は通常このパラメータをオンにします。

しかし、私はこのパラメータのせいで落とし穴に陥ってしまいました:

同社のニュース公開用 CMS バックエンド システムは、haproxy+keepalived プロキシ アーキテクチャを使用しており、バックエンドの実サーバーの外部 IP アドレスはすべて削除されています。

現象: ある朝の投稿ピーク時に、CMS バックエンドでアクセス障害が発生しました。PHP サービスを再起動するとすぐに有効になりますが、しばらくすると再びアクセスが失敗します。

nginx と php のログを確認しましたが、何も見つかりませんでした。後で Google で検索したところ、問題の原因は net.ipv4.tcp_tw_recycle パラメータであることがわかりました。

このネットワーク アーキテクチャは、バックエンド リアルサーバーの NAT モードです。このパラメータをオンにすると、多数の TCP 接続確立エラーが発生し、Web サイトへのアクセスが失敗します。

最後に、net.ipv4.tcp_tw_recycle を 0 に設定します。この機能をオフにすると、バックグラウンド アクセスはすぐに正常に戻ります。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。