Nginxのパフォーマンス最適化方法

Linux システム パラメータの最適化

以下で説明する構成の一部には、新しい Linux (2.6 以降) カーネルが必要です。筆者は CentOS 7.4 とカーネル バージョン 3.10 を使用していますが、ニーズを満たしていない場合は、適宜アップグレードするのが最善です。結局のところ、パッチ適用はありがたい作業です。システムレベルのチューニングでは、通常、ファイル記述子の制限、バッファーキューの長さ、および一時ポートの数を変更するだけです。

ファイル記述子の制限

各 TCP 接続はファイル記述子を占有するため、ファイル記述子が使い果たされると、問題を改善するために、新しい接続ではこのエラーのような「開いているファイルが多すぎます」が返されます。 1. システム レベルの制限編集ファイル /etc/sysctl.conf に、次の内容を追加します。

fs.file-max =10000000
fs.nr_open =10000000

ユーザー レベルの制限編集ファイル /etc/security /limits.conf、次のコンテンツを追加します:

 *      hard   nofile      1000000
 *      soft   nofile      1000000

ユーザー レベルの制限がシステム レベルの制限より低いことを確認する必要があります。そうしないと、SSH 経由でログインできなくなります。変更が完了したら、次のコマンドを実行します。

 $ sysctl -p

コマンド ulimit -a を実行すると、変更が成功したかどうかを確認できます。

TCP 接続キューの長さ

ファイル /etc/sysctl.conf を編集し、次の内容を追加します。

# The length of the syn quenenet.ipv4.tcp_max_syn_backlog =65535# The length of the tcp accept queuenet.core.somaxconn =65535

このうち、tcp_max_syn_backlog は、準接続を指定するために使用されます。 SYN キューの長さ。新しい接続が確立されると、接続が到着すると、システムは半接続中の SYN キューを検出します。キューがいっぱいの場合、SYN リクエストは処理できず、統計カウントが ListenOverflows および ListenDrops に追加されます。 /proc/net/netstat.somaxconn は、完全接続された ACCEPT キューの長さを指定するために使用されます。キューがいっぱいの場合、クライアントによって送信された ACK パケットは正しく処理されず、「ピアによって接続がリセットされました」というエラーが返されます。 Nginx は、「アップストリームへの接続中にライブ アップストリームがありません」というエラー ログを記録します。上記のエラーが発生した場合は、これら 2 つの項目の設定を増やすことを検討する必要があります。

一時ポート

Nginx がプロキシとして使用されるため、アップストリーム Web サービスへの各 TCP 接続は一時ポートを占有するため、ip_local_port_range パラメータを変更して /etc/

net.ipv4.ip_local_port_range =102465535
net.ipv4.ip_local_reserved_ports =8080,8081,9000-9010

このうち、パラメータ ip_local_reserved_ports は、サービスポートが占有されて起動できなくなることを防ぐための予約ポートの指定に使用されます。

Nginx パラメーターの最適化

Nginx パラメーターの最適化は、主に nginx.conf 構成ファイルに焦点を当てていますが、以下では詳しく説明しません。

ワーカー プロセス

Nginx の強力なパフォーマンスの重要な理由は、Nginx がマルチプロセスのノンブロッキング I/O モデルを採用しているため、これを有効に活用する必要があります。

• worker_processes デフォルトでは、Nginx にはマスター プロセスとワーカー プロセスが 1 つだけあります。これを変更する必要があります。指定した数または CPU の数である auto に設定できます。システムの中核。ワーカーの数が増えると、プロセス間で CPU リソースの競合が発生し、不必要なコンテキストの切り替えが発生する可能性があります。したがって、これを CPU コアの数に設定するだけです。 worker_processes auto

• worker_connections 各ワーカーが処理できる同時接続の数。デフォルト値の 512 はそうではありません。十分に十分です。使用する場合は、適切に増やします:worker_connections 4096

• Nginx は、接続を処理するために次の I/O 多重化メソッドをサポートしています: select、pol、kqueue、 epoll、rtsig、/dev/poll、eventport。オペレーティング システムが異なれば使用するツールも異なります。Linux システムでは epoll が最も効率的です。

KeepAlive

Nginx から Web サービスへの頻繁な変更を避けるため接続の確立と切断には、HTTP 1.1 からサポートされている KeepAlive 長時間接続機能を有効にすることで、CPU とネットワークのオーバーヘッドを大幅に削減でき、実際の戦闘においても最大のパフォーマンス向上を実現します。 Keepalive は、proxy_http_version および proxy_set_header と組み合わせて使用​​する必要があります。参照構成は次のとおりです:

upstream BACKEND {
    keepalive 300;
     server 127.0.0.1:8081;
 }
server {
     listen 8080;
    location /{
        proxy_pass http://BACKEND;
        proxy_http_version 1.1;
        proxy_set_header Connection"";
 }
}

ここで、keepalive はタイムアウトでも接続プールの数でもありません。公式の説明は次のとおりです:

接続パラメーターは、各ワーカー プロセスのキャッシュに保存される上流サーバーへのアイドル状態のキープアライブ接続の最大数を設定します。この数を超えると、最も最近使用されていない接続が閉じられます。

次のことがわかります。これは「アイドル状態の長い接続の最大数」を意味します。この数を超えるアイドル状態の長い接続はリサイクルされます。リクエストの数が安定していてスムーズな場合、アイドル状態の長い接続の数は非常に少なくなります (0 に近くなります)。実際には、リクエストの数は常にスムーズで安定しているとは限りません。リクエストの数が変動すると、アイドル状態の長い接続の数も変動します。

1. #アイドル状態の長い接続の数が増えると、設定値を超えると、設定値を超える長い接続の部分がリサイクルされます。 ;

2. 長い接続が十分でない場合は、新しい長い接続が再実行されます。設立。

如果该值过小，连接池会经常进行回收、分配和再回收操作。为了避免这种情况出现，可以根据实际情况适当调整这个值，在我们实际情况中，目标QPS为6000，Web服务响应时间约为200ms，因此需要约1200个长连接，而 keepalive值取长连接数量的10%~30%就可以了，这里我们取300，如果不想计算，直接设为1000也是可行的。

Access-Log缓存

记录日志的I/O开销比较高，好在Nginx支持日志缓存，我们可以利用这个功能，降低写日志文件的频率，从而提高性能。结合使用buffer和flush两个参数可以控制缓存行为

  access_log /var/logs/nginx-access.log buffer=64k gzip flush=1m

其中 buffer制定了缓存大小，当缓冲区达到 buffer所指定的大小时，Nginx就会将缓存起来的日志写到文件中；flush指定了缓存超时时间，当 flush指定的时间到达时，也会触发缓存日志写入文件操作。

文件描述符限制

Nginx配置中同样有相应的配置项：worker_rlimit_nofile, 理论上这个值应该设置为 /etc/security/limits.conf 中的值除以 worker_processes, 但实际中不可能每个进程均匀分配，所以这里只要设置成和 /etc/security/limits.conf 一样就可以了

 worker_rlimit_nofile 1000000;

以上がNginxのパフォーマンス最適化方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。