[TOC]

nginxのパラメータ、パフォーマンスの最適化の設定

Linuxシステムレベル

接続追跡パラメータ

一般的に、パフォーマンスに影響を与えるには大きすぎるバレルを防ぐために、1/4または1/2 nf_conntrack_maxをnf_conntrack_buckets、200ワットにnf_conntrack_max設定。

$ cat /proc/sys/net/netfilter/nf_conntrack_buckets
524288

$ cat /proc/sys/net/netfilter/nf_conntrack_max
2097152
复制代码

バックログキュー

net.core.somaxconn
- 接続の最大数は、nginxのが受け入れるキューに入れることができます。一般的に小さすぎるnginxのパフォーマンスの問題が生じた場合は、カーネルを表示することができますが、状態を発見したログ
- 一緒にnginxのを調整するための指示には耳を傾けます。
net.core.netdev_max_backlog
- CPUカードの前にレート・バッファに送信されたパケットは、この値は、機械の性能を改善するために増加し、高い帯域幅を有することができます

ファイルディスクリプタ

ファイル記述子はオープンで接続されたファイルを表すために使用されるオペレーティングシステムのリソースです。2つのnginxのファイル記述子の最大に接続することができます。例えば、ファイル記述子、ファイル記述子、及び上流接続後端部に接続されたリバースプロキシ、およびクライアントとして。

sys.fs.file-MAX
- Linuxのファイルシステムは、説明の最大数を可能に
- 猫を/ proc / sys / fs /ファイルマックス
NOFILE
- ファイル記述子の最大数は、一般的な設定は、アプリケーションレベルの許可/etc/security/limits.confファイル

ポート

net.ipv4.ip_local_port_range
- ポートのポート範囲
圧力測定終了、もし短いリンク
- net.ipv4.tcp_tw_reuse = 1
  - これは、開いているポートの多重化を表します。TIME-WAITソケットは、新しいTCP接続のために再使用できるように、デフォルトではオフを示し、0です。
- net.ipv4.tcp_tw_recycle = 1
  - それは、デフォルトは0で、オープンTCP接続のTIME-WAITソケットの急速な回復をオフに表します。

nginxのレベル

開いているファイル

worker_rlimit_nofile 65535;
- 最大ファイルディスクリプタのオープンファイルnginxのワーカープロセス（RLIMIT_NOFILE）

労働者は、プロセスのプロセス番号

worker_processes
- 通常はオートに設定されているので、CPUはnginxのワーカープロセスであります
worker_connections
- ワーカー・プロセスごとの接続の最大数は、一般に、655350のように、この数の大流量の場合に上げなければなりません

キープアライブ接続長い接続

keepalive_requests
- クライアント要求の最大数は、キープアライブを使用して送信することができます
keepalive_timeout
- アクティブな接続を維持するための最大タイムアウト
生き続ける
- これは、各ワーカー・プロセスのために開いたままでアクティブな接続の数に上流アイドル状態のままです。

上流の長いリンクの後端を使用することができます保つためには、次の設定を行う必要があります。

proxy_http_version 1.1;
proxy_set_header Connection "";   
复制代码

イベント【multi_accept】

multi_acceptなっnginxのワーカープロセスは、一度、すべての新しい接続を受け取ることができる表現する場合は、以下の手順では、デフォルトではオフになって、一度だけnginxのワーカープロセスは、新しい接続を受信します：

Syntax:	multi_accept on | off;
Default:	
multi_accept off;
Context:	events
复制代码

events {
        worker_connections 655350; 
        multi_accept on;
}
复制代码

しかし、一般的に、あなたは、現場での全体的なパフォーマンスは、短い接続が改善されますが、問題の要求の一部を思い付くムラを避けるために、開く必要がありますが、少し利点はありません。

ロギング

アクセスログ

各要求をロギングすると、CPUとI / Oサイクルを大量に消費します、影響を低減するための方法は、ログバッファへのアクセスを可能にするためです。nginxのは、書き込みログエントリの後に、各使用のために別のバッファを実行しないが、一連のエントリは、バッファ、およびその動作は一緒にファイルに書き込まれます。

でaccess_logの増加バッファ=サイズ指示は、この機能を有効にすることができ、したがって、バッファが一杯になった場合は、ログファイルに書き込まれる、フラッシュ=時間パラメータは、定期的にログファイルにブラシのバッファを記録することができ、

エラーログ

/usr/local/nginx/logs/nginx_error.logエラーをerror_logに。

ここでのことに注意してくださいエラーログ、エラーのみレベル以上のエラーログに出力されることを意味します。ここではレベルが含まれますwarn, error , crit, alert, emerg。使用説明書は、の公式ウェブサイトを参照のerror_log

レベルnginxのLuaの参照ログnginxのログレベル定数を

企業を介してオンラインで、一般的にエラーのレベルを超えると、アラーム処理マイクロチャネル

ファイルを送信

オペレーティング・システムTCPデータ伝送を加速することができる一般にゼロコピーを達成するために使用される他の記述子にファイル記述子からデータをコピーするためのsendfile（）システムコール、。sendfileを指示またはHTTPサーバーの場所のコンテキストまたはコンテキストを備え、nginxのを使用することを可能にします。その後、nginxのは非常に高速書き込みを行い、ユーザ空間に任意のコンテキストスイッチなしで、ディスク上またはソケットにコンテンツをキャッシュし、少ないCPUサイクルを消費します。しかし、以降のsendfile（）は、取り扱いの正規nginxのチェーンを受けないので、空間の周りにユーザデータをコピーして（例えば、GZIPなど）フィルタの内容を変更する、A。sendfileのコンフィギュレーションコンテキストがフィルタの内容を変更する命令と活性化命令が含まれている場合、nginxのは自動的にコンテキストのsendfileを無効にします。公式sendfileを次のように説明したが、注意、DIRECTIOは自動的にsendfileを無効にします。

In this configuration, sendfile() is called with the SF_NODISKIO flag which causes it not to block on disk I/O, but, instead, report back that the data are not in memory. nginx then initiates an asynchronous data load by reading one byte. On the first read, the FreeBSD kernel loads the first 128K bytes of a file into memory, although next reads will only load data in 16K chunks. This can be changed using the read_ahead directive.
复制代码

次のように使用します。

http {
    sendfile on;
}
复制代码

制限

設定の制限は、nginxのサーバーは、いくつかの問題を引き起こすあまりにも多くのリソースを消費クライアントを防ぐように設計されています。一般的に降格するために使用します。

limit_connとlimit_conn_zone
- たとえば、IPの制限として、nginxのを受け入れるためのクライアント接続の数を制限
- あまりにも多くの接続を開くために、単一のクライアントを防ぎ、資源の消費は、リソースのシェアを超えています。
limit_rate
- 各クライアントは、速度制限応答に接続されたクライアント接続の複数を、各接続は、この速度を達成することができます
- これにより、すべてのクライアントにサービスの高品質を保証する、いくつかのクライアントを過負荷からシステムを防ぎます。
limit_reqとlimit_req_zone
- nginxの処理要求レート制限、limit_rateと同様の効果。
MAX_CONNS
- MAX_CONNSサーバコマンドのパラメータ、後端の上流の最大接続制限、後端が上流接続の最大許容数を表します。

バッファ

client_body_buffer_size
- 要求されたデータの最大サイズは、クライアントから読み込まれます
client_header_buffer_size
- クライアントからの読み出し要求ヘッダ最大データ
client_max_body_size
- クライアント側の要求の最大サイズを設定し、または413を返すエンティティが大きすぎる要求限度を超えます
large_client_header_buffers
- 大規模なクライアントヘッダーの最大サイズを設定します。

次のように推奨される値は次のとおりです。

client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 8m;
large_client_header_buffers 4 4k;
复制代码

タイムアウト

client_header_timeout＆client_body_timeout
- 要求が開始されると、nginxのクライアントがタイムアウトヘッダや本文を待って送信します
keepalive_timeout
- nginxの長い接続がアイドルタイムアウト時間のまま
send_timeout
- クライアントのタイムアウトに応答して、タイムアウトがnginxのアクティブな接続を閉じている場合

次のように推奨される値は次のとおりです。

client_body_timeout 12;
client_header_timeout 12;
keepalive_timeout 15;
send_timeout 10;
复制代码

いくつかの接続タイムアウトがあります。

proxy_connect_timeout 60;
proxy_send_timeout 60;
proxy_read_timeout 60;
复制代码

他の構成

主配置

user  www www;

worker_processes auto;

error_log  /usr/local/nginx/logs/nginx_error.log  error;
pid    /usr/local/nginx/nginx.pid;

worker_rlimit_nofile 65535;

events
{
    use epoll;
    worker_connections 65535;
}

复制代码

TCP_NODELAY

次のように使用します。

http {
    sendfile on;
    tcp_nodelay on;
}
复制代码

GZIP

gzip on;
    	gzip_vary on;
    	gzip_proxied any;
    	gzip_comp_level 1;
    	gzip_buffers 16 8k;
    	gzip_http_version 1.1;
    	gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
复制代码

オープンファイルキャッシュ

参照

パフォーマンスのためにnginxのチューニング

どのようにチューニングするとnginxのWebサーバーのパフォーマンスを最適化

[「：う積極的に公共のマイクロチャンネル数でのLinuxサーバーシステムの開発、品質の記事を送り返す私は公共のマイクロチャネル番号の関心を歓迎します」]