Nginx 構成とカーネルを最適化する方法-Nginx-php.cn

nginx 命令の最適化 (設定ファイル)

コードをコピーコードは次のとおりです:

worker_processes 8;

nginx プロセスの数は推奨されますCPU の数に基づいて指定します。通常はその倍数で指定します。

コードをコピー次のようにコード:

worker_cpu_affinity 0000000010 00000100001000 00010000 00100000 01000000000;

## すべての CPU をプロセスごとに分散します。CPU、もちろん複数に書き込むことも、割り当てることもできます。プロセスを複数の CPU に転送します。

コードをコピーしますコードは次のとおりです:

worker_rlimit_nofile 102400;

この命令は、nginx プロセスによって開かれるファイル記述子の最大数を指します。理論値は次のようになります。開いているファイルの最大数 (ulimit -n) は nginx プロセスの数で除算されますが、nginx はリクエストをそれほど均等に割り当てないため、値を ulimit -n と一致させることが最善です。

コードをコピーコードは次のとおりです:

use epoll;

Use epoll's i/o model. これは言うまでもありません。

コードをコピーしますコードは次のとおりです:

worker_connections 102400;

各プロセスで許可される接続の最大数理論的には、nginx サーバーごとの最大接続数は次のとおりです。ワーカープロセス * ワーカー接続。

コードをコピーするコードは次のとおりです:

keepalive_timeout 60;

キープアライブタイムアウト時間。

コードをコピーしますコードは次のとおりです:

client_header_buffer_size 4k;

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

コードをコピーしますコードは次のとおりです:

open_file_cache max=102400 inactive=20s;

これにより、開いているファイルのキャッシュが指定されます。デフォルトでは有効になっていません。 .max はキャッシュの数を指定します。開いているファイルの数と一致させることをお勧めします。非アクティブとは、キャッシュが削除されるまでにファイルが要求されていない期間を指します。

コードをコピーします。コードは次のとおりです:

open_file_cache_valid 30s;

これは、キャッシュされた有効な情報を確認する頻度を指します。

コードをコピーしますコードは次のとおりです:

open_file_cache_min_uses 1;

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

カーネルパラメータの最適化

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_max_tw_buckets = 6000

timewait の数 (デフォルト)は180000です。

コードをコピーします。コードは次のとおりです。

net.ipv4.ip_local_port_range = 1024 65000

システムによって開くことが許可されているポート範囲。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_tw_recycle = 1

timewait 高速リサイクルを有効にします。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_tw_reuse = 1

再利用をオンにします。新しい TCP 接続に時間待機ソケットを再利用できるようにします。

コードをコピーコードは次のとおりです:

net.ipv4.tcp_syncookies = 1

syn cookie をオンにします。syn 待機キューがオーバーフローした場合、cookie を有効にして処理します。。

コードをコピーします。コードは次のとおりです。

net.core.somaxconn = 262144

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

コードをコピーします。コードは次のとおりです。

net.core.netdev_max_backlog = 262144

各ネットワークインターフェイスがパケットを受信する速度が、パケットを受信する速度よりも速い場合カーネルはこれらのパケットを処理し、キューに送信されるパケットの最大数を許可します。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_max_orphans = 262144

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

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_max_syn_backlog = 262144

クライアント確認情報をまだ受信していない、記録された接続要求の最大値。 128m のメモリを備えたシステムの場合、デフォルト値は 1024 で、メモリが小さいシステムの場合は 128 です。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_timestamps = 0

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

コードをコピーします。コードは次のとおりです:

net.ipv4.tcp_synack_retries = 1

ピアへの接続を開くために、カーネルは syn を送信する必要があります。前の同期に対する応答として ack が含まれます。これは、いわゆる 3 ウェイハンドシェイクにおける 2 回目のハンドシェイクです。この設定は、カーネルが接続を放棄する前に送信される同期パケットの数を決定します。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_syn_retries = 1

カーネルが接続の確立を断念する前に送信される syn パケットの数。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_fin_timeout = 1

ソケットがローカルエンドによって閉じるように要求された場合、このパラメータは次のように決定します。 fin-wait-2 状態時間のままになります。ピアがエラーを起こして接続を閉じなかったり、予期せずクラッシュしたりする可能性があります。デフォルト値は 60 秒です。 2.2 カーネルの通常の値は 180 秒です。この設定を押すこともできますが、マシンの負荷が軽い Web サーバーであっても、多数のデッドソケット、フィンによるメモリオーバーフローのリスクがあることに注意してください。 wait-2 は最大 1.5k のメモリしか消費できないため、fin-wait-1 よりも危険性は低くなりますが、寿命は長くなります。

コードをコピーします。コードは次のとおりです。

net.ipv4.tcp_keepalive_time = 30

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

完全なカーネル最適化構成

コードをコピーします。コードは次のとおりです。

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_max_tw_buckets = 6000
net.ipv4.tcp_sack = 1
net.ipv4 .tcp_window_scaling =1 .core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 262144
net.ipv4.tcp_max_orphans = 3276800
net .ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_tw_recycle = 1
net .ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_keepalive_time = 30
net.ipv4.ip_local_port_range = 1 024 65000

簡単な nginx 最適化構成ファイル

コードをコピーしますコードは次のとおりです:

user www www;

worker_processes 8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 ;

error_log /www/log/nginx_error.log crit;

pid /usr/local/nginx/nginx.pid;

worker_rlimit_nofile 204800;

イベント
{
epoll を使用する;
worker_connections 204800;
}

http
{
mime.types を含める;
default_type application/octet-stream;

charset utf -8;

server_names_hash_bucket_size 128;
client_header_buffer_size 2k;
large_client_header_buffers 4 4k;
client_max_body_size 8m;

sendfile on;
tcp_nopush on;

keepalive_timeout 60;

fastcgi_cache_path /usr/local/nginx/fastcgi_cache tables=1:2
keys_zone=test:10m
inactive=5m;
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 16k;
fastcgi_buffers 16 16k;
fastcgi_busy_buffers_isize 16k CGI_CACHEテスト;
FASTCGI_CACHE_VALID 200 30 2 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale エラータイムアウト valid_header http_500;

open_file_cache max=204800 inactive=20s;
open_file_cache_min_uses 1;
open_file_cache_valid 30s;

tcp_nolay オン;

gzip オン;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.0;
gzip_comp_level 2 ;
gzip_types text/plain application/x-javascript text/css application/xml;
gzip_vary on;

server
{
listen 8080;
server_name ad.test.com;
indexindex.phpindex.htm;
root /www/html/;

location /status
{
stub_status on;
}

location ~ .*\.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_indexindex.php;
include fcgi.conf;
}

location ~ .*\.(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 access;
}
}

fastcgi に関するいくつかの手順

コードをコピーするコードは次のとおりです。

fastcgi_cache_path /usr/ local/nginx/fastcgi_cache tables=1:2 key_zone=test:10m inactive=5m;

このディレクティブは、パス、ディレクトリ構造レベル、キーワード領域の保存時間、およびfastcgi キャッシュの非アクティブな削除時間。

コードをコピーします。コードは次のとおりです。

fastcgi_connect_timeout 300;

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

コードをコピーします。コードは次のとおりです。

fastcgi_send_timeout 300;

fastcgi へのリクエスト送信のタイムアウト: この値は、2 回のハンドシェイクが完了した後の fastcgi へのリクエスト送信のタイムアウトを指します。

コードをコピーしますコードは次のとおりです:

fastcgi_read_timeout 300;

fastcgi 応答受信のタイムアウトこの値は、2 回のハンドシェイク後の fastcgi 応答受信のタイムアウトを指します。完成しました。

コードをコピーしますコードは次のとおりです:

fastcgi_buffer_size 16k;

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

コードをコピーします。コードは次のとおりです:

fastcgi_buffers 16 16k;

上記のように、fastcgi 応答をバッファリングするために使用する必要があるローカルバッファーの数と大きさを指定します。 , phpの場合スクリプトで生成されたページサイズは256kで、キャッシュ用に16kのバッファが16個割り当てられます 256kより大きい場合は、256kより大きい部分はfastcgi_tempで指定したパスにキャッシュされますもちろんこれですこれはサーバーの負荷にとって良くありません。メモリ内のデータ処理速度はハードディスクよりも速いため、通常、この値の設定には、サイト内の PHP スクリプトによって生成されるページサイズの中間値を選択するのが賢明な解決策です。 , サイト内のほとんどのスクリプトによって生成されたページなどです。サイズが 256k の場合、この値を 16 16k、または 4 64k または 64 4k に設定できますが、明らかに、後者の 2 つは適切な設定方法ではありません。生成されたページが 32k のみの場合、4 64k が使用されている場合は 1 つの 64k バッファがキャッシュに割り当てられ、64 4k が使用されている場合は 8 つの 4k バッファがキャッシュに割り当てられ、16 16k が使用されている場合は、ページをキャッシュするために 2 つの 16k バッファが割り当てられますが、これはより合理的と思われます。

コードをコピーしますコードは次のとおりです:

fastcgi_busy_buffers_size 32k;

このコマンドが何をするのかわかりません。デフォルト値がサイズの 2 倍であることだけがわかります。 fastcgi_buffers の。

コードをコピーしますコードは次のとおりです:

fastcgi_temp_file_write_size 32k;

fastcgi_temp_path を書き込むときに使用されるデータブロックの大きさ。デフォルト値は fastcgi_buffers のサイズの 2 倍です。。

コードをコピーします。コードは次のとおりです。

fastcgi_cache test

fastcgi キャッシュをオンにし、名前を付けます。個人的には、キャッシュをオンにすることは、CPU 負荷を効果的に軽減し、502 エラーを防ぐことができるため、非常に便利だと感じています。ただし、このキャッシュは動的ページをキャッシュするため、多くの問題を引き起こします。具体的な使用方法は、お客様自身のニーズによって異なります。

コードをコピーします。コードは次のとおりです。

fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;

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

コードをコピーします。コードは次のとおりです。

fastcgi_cache_min_uses 1;

fastcgi_cache_path ディレクティブの非アクティブなパラメーター値内でのキャッシュの最小使用数。上の例では、ファイルが 5 分以内に使用された場合、一度も使用されなかった場合、ファイルは削除されます。

コードをコピーコードは次のとおりです:

fastcgi_cache_use_stale error timeout valid_header http_500;

このパラメータの機能がわかりません。nginx に知らせるべきだと思います。どのタイプのキャッシュが役に立たないのか。上記は nginx の fastcgi に関連するパラメータです。また、fastcgi 自体にも最適化が必要な設定がいくつかあります。fastcgi を管理するために php-fpm を使用する場合は、設定ファイル内の以下の値を変更できます:

コードをコピーします。コードは次のとおりです。

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

コードをコピーします。コードは次のとおりです。

102400

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

コードをコピーします。コードは次のとおりです。

204800

各プロセスが実行できるリクエストの最大数番号をリセットする前に実行してください。

いくつかのテスト結果

静的ページは、Squid で 4w 同時実行を構成した記事で説明されているテストファイルです。下の図は、6 台のマシンで webbench -c 30000 -t を実行しているところを示しています。 600 回後のテスト結果 http://ad.test.com:8080/index.html コマンド:

Nginx 構成とカーネルを最適化する方法

netstat を使用してフィルタリングされた接続の数:

Nginx 構成とカーネルを最適化する方法

ステータスの php ページの結果 (php ページが phpinfo を呼び出す):

Nginx 構成とカーネルを最適化する方法

実行後の php ページの接続数netstat フィルタリング:

Nginx 構成とカーネルを最適化する方法

fastcgi キャッシュが使用される前のサーバー負荷:

Nginx 構成とカーネルを最適化する方法

この時点で php ページを開くことはすでに困難であり、複数のファイルが必要です更新して開きます。上図で cpu0 の負荷が低いのは、テスト中にすべてのネットワークカード割り込み要求が cpu0 に割り当てられ、nginx で 7 つのプロセスが開かれ、それぞれ cpu1 ～ 7 に割り当てられたためです。

fastcgi キャッシュを使用した後:

Nginx 構成とカーネルを最適化する方法