Nginx 構成とカーネルを最適化する方法
- WBOY転載
- 2023-05-16 21:43:271387ブラウズ
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 最適化構成ファイル
コードをコピーしますコードは次のとおりです:
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 へのリクエスト送信のタイムアウト: この値は、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 個の子スレッドが開かれます。
コードをコピーします。コードは次のとおりです。
開いているファイルの最大数。
コードをコピーします。コードは次のとおりです。
各プロセスが実行できるリクエストの最大数番号をリセットする前に実行してください。
いくつかのテスト結果
静的ページは、Squid で 4w 同時実行を構成した記事で説明されているテスト ファイルです。下の図は、6 台のマシンで webbench -c 30000 -t を実行しているところを示しています。 600 回後のテスト結果 http://ad.test.com:8080/index.html コマンド:
netstat を使用してフィルタリングされた接続の数:
ステータスの php ページの結果 (php ページが phpinfo を呼び出す):
実行後の php ページの接続数netstat フィルタリング:
fastcgi キャッシュが使用される前のサーバー負荷:
この時点で php ページを開くことはすでに困難であり、複数のファイルが必要です更新して開きます。上図で cpu0 の負荷が低いのは、テスト中にすべてのネットワーク カード割り込み要求が cpu0 に割り当てられ、nginx で 7 つのプロセスが開かれ、それぞれ cpu1 ～ 7 に割り当てられたためです。
fastcgi キャッシュを使用した後:
この時点で、php ページを簡単に開くことができます。
このテストはデータベースに接続していないので参考値はありませんが、上記のテストが限界に達しているかどうかはわかりませんが、メモリやCPUの使用状況によるものではないようですが、追加のマシンはないので、Web ベンチを実行させてください。
以上がNginx 構成とカーネルを最適化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。