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

Nginx は、非常に人気のある成熟した Web サーバーおよび予備プロキシ サーバーです。インターネット上にはパフォーマンス最適化のチュートリアルが多数ありますが、どのような構成が最適であるかは、多くのテストと必要になります。継続的な最適化を実践します。最近、ユーザーからの問い合わせ数が 100 万件を超えた後、それほど複雑ではないものの、解決に時間がかかり、多くの経験が蓄積されました。

この問題は、実際にしばらく前から発生しており、通話がタイムアウトするという報告を受けていましたが、弊社のシステム監視によれば、それはわずか数十ミリ秒であり、タイムアウトすることはありません。ネットワークに原因があるのか​​と思いましたが、何度か発生した後、この問題は偶然ではなく、根深い理由があるのではないかと漠然と感じました。

当社のサービスは企業顧客向けであるため、各顧客の通話量は非常に多くなる可能性がありますが、各企業顧客が持つパブリック ネットワーク IP は数個だけです。将来的に顧客が数千人になったとしても、Nginx はこれらの同時接続を簡単にサポートできます。接続。そのため、まずネットワークからの Nginx の長い接続を最適化し、元の構成から長い接続を変更し、毎回の接続リクエストの数をデフォルトの 100 から 1000 に調整しました。 5秒钟改成5分钟

<code>keepalive_timeout  300;
keepalive_requests 1000;</code>

調整完了後、

netstatを渡す -anp コマンドからわかるように、新しい接続リクエストの数が減少し、長時間の接続が機能していることがわかります。しかし、しばらく経っても、Nginx ログから、以下に示すように、リクエスト時間が依然として 1 秒を超え、最長で約 20 秒であることがわかります。 そして、Zabbix 上の監視から、接続の書き込みまたはアクティブの数が急激に増加すると、それに応じてリクエスト時間が表示され、タイムアウトが増加します:

アプリケーションのログを確認すると、実行時間が長くありません:

アプリケーション内でカウントされる時間は、業務の実行開始から実行結果までの時間のみです。これには、Tomcat コンテナの実行時間は含まれません。

<code>client --> Nginx -->  Tomcat --> App</code>

Tomcat コンテナ自体が実行されている可能性はありますか? 問題については、Tomcat リクエスト ログを呼び出したところ、この時点の前後の実行も正常であることがわかりました。 リクエスト パスの分析から、Nginx から Tomcat レイヤーにいくつかの問題があるはずです。この問題のトラブルシューティングを行っているときに、突然約 30 秒のタイムアウトが大量に発生していることに気づきました。これは Zabbix
接続でも観察されました。 以下に示すように、書き込み

が非常に多くなっています:

同時に、
TIME_WAIT

での接続が非常に多いことがわかります。現象とパケット キャプチャの分析結果から判断すると、いくつかの接続が発生しているはずです。顧客は長い接続を有効にしていないため、サーバー側でも

keepalive_timeout を 5 分に設定しました。これにより、その時点で 2,000 近くの使用済み接続が発生しました。 etc/sysctl.conf ファイルに次の 2 つのパラメータを追加して接続を再利用します:

<code>net.ipv4.tcp_tw_reuse = 1 #表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；
net.ipv4.tcp_tw_recycle = 1 #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。</code>

すぐに有効になります Zabbix モニタリング、connection からわかるように、すぐに 200 を下回りました。 書き込み
と接続アクティブ`の両方が大幅に低下しましたが、問題は完全に解決されていないため、他の原因を見つける必要があります。

TIME_WAIT的连接特别多，从现象及抓包分析结果来看，应该是有客户没有开启长连接，而我们在服务端又设置了keepalive_timeout为5分钟，导致大量使用过的连接等待超时，当时有接近2000个，编辑/etc/sysctl.conf

Nginx の reqeust_time

は、クライアントが最初のバイトを受信して​​からバックエンドのアップストリームを呼び出すまでの時間を指します サーバーがビジネス ロジックの処理を完了し、返されたすべての結果をクライアントに書き戻すまでの時間。上流のサーバーを呼び出した時間を出力できれば、幸いにも Nginx には問題の範囲を絞り込むのが簡単になります。バックエンド サーバーによって要求された時刻と IP アドレスを出力するには、nginx.conf ファイルのログ形式を次のように変更します:

<code># $upstream_response_time 后端应用服务器响应时间
# $upstream_addr 后端服务器IP和端口号
log_format  main  '$remote_addr - [$time_local] "$request" '
                      '$status $body_bytes_sent '
                      '"$request_time" "$upstream_response_time" "$upstream_addr" "$request_body "';</code>

もう一度ログを見ると、特に長い呼び出しのほとんどが行われていることが非常に明白です。同じマシンから来ています:

reqeust_time

このマシンを見ると、Java プロセスはまだ存在していますが、アプリケーションは実際にクラッシュしており、実際のリクエストは入ってきていないことがわかりました。負荷分散からこのマシンを削除し、問題はすぐに軽減されます:

このマシンは実際にハングアップしましたが、なぜ Nginx がそれを認識しなかったのでしょうか?さらに調査を行った結果、Nginx がアップストリーム サーバーを呼び出すときのデフォルトのタイムアウトは 60 秒であることがわかりました。そのため、nginx.conf ファイルでデフォルトのタイムアウトを変更し、それを超える場合は返します。 1秒を超えます:

<code># time out settings  
proxy_connect_timeout 1s;  
proxy_send_timeout   1s;  
proxy_read_timeout   1s;</code>

运行一段时间后，问题已基本得到解决，不过还是会发现request_time超过1s达到5s的，但upstream_response_time都没有超时了，说明上面的参数已起作用。

版权声明：本文为博主原创文章，未经博主允许不得转载。

以上就介绍了Nginx 性能优化，包括了方面的内容，希望对PHP教程有兴趣的朋友有所帮助。