Nginxのパフォーマンス最適化方法-Nginx-php.cn

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

王林

リリース： 2023-05-28 08:01:51

転載

1271 人が閲覧しました

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 に近くなります)。実際には、リクエストの数は常にスムーズで安定しているとは限りません。リクエストの数が変動すると、アイドル状態の長い接続の数も変動します。

#アイドル状態の長い接続の数が増えると、設定値を超えると、設定値を超える長い接続の部分がリサイクルされます。 ;
長い接続が十分でない場合は、新しい長い接続が再実行されます。設立。

如果该值过小，连接池会经常进行回收、分配和再回收操作。为了避免这种情况出现，可以根据实际情况适当调整这个值，在我们实际情况中，目标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 一样就可以了