web-dev-qa-db-ja.com

高負荷時にWebサーバーがTCPを使用して接続をドロップするのはなぜですか？

Nginxで小さなVPSを設定しています。私はそれから可能な限り多くのパフォーマンスを絞り出したいので、最適化と負荷テストを実験しています。

Blitz.ioを使用して小さな静的テキストファイルをGETすることで負荷テストを行っており、サーバーが送信しているように見える奇妙な問題に遭遇していますTCP同時接続数に達するとリセットされますおおよそ2000年です。これは非常に大きな量ですが、htopを使用することで、サーバーにはCPU時間とメモリがまだ十分にあるため、この問題の原因を突き止めて、さらにプッシュできるかどうかを確認したいと思います。 。

Ubuntu 14.04 LTS（64ビット）を2GB Linode VPSで実行しています。

このグラフを直接投稿するのに十分な評判がないので、これがBlitz.ioグラフへのリンクです。

enter image description here

問題の原因を突き止め、理解するために私が行ったことは次のとおりです。

  • Nginx設定値worker_rlimit_nofileは8192に設定されています
  • nofileをwww-dataのrootおよび/etc/security/limits.confユーザー（nginxの実行方法）のハード制限とソフト制限の両方で64000に設定します。

  • /var/log/nginx.d/error.logで問題が発生している兆候はありません（通常、ファイル記述子の制限に達している場合、nginxはそのことを示すエラーメッセージを出力します）

  • 私はufwセットアップを持っていますが、レート制限ルールはありません。 ufwログは何もブロックされていないことを示しており、同じ結果でufwを無効にしてみました。

  • /var/log/kern.logには指示的なエラーはありません
  • /var/log/syslogには指示的なエラーはありません

  • 以下の値を/etc/sysctl.confに追加し、それらにsysctl -pをロードしても効果はありません。

    net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 1024
net.core.netdev_max_backlog = 2000

何か案は？

EDIT：非常に小さなファイル（3バイトのみ）で3000接続に増加する新しいテストを行いました。これがBlitz.ioのグラフです。

Blitz.io graph

繰り返しますが、Blitzによると、これらのエラーはすべて「TCP接続リセット」エラーです。

これはLinode帯域幅グラフです。これは5分間の平均であるため、ローパスフィルターがかけられていることに注意してください（瞬間的な帯域幅はおそらくはるかに高いです）が、それでも何もありません。

enter image description here

CPU：

enter image description here

I/O：

enter image description here

テスト終了間際のhtopは次のとおりです。 htop

エラーが発生し始めたときにキャプチャを開始して、別の（ただし、似たような）テストでtcpdumpを使用してトラフィックの一部をキャプチャしました：Sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

誰かがそれを見てみたい場合のファイルは次のとおりです（〜20MB）： https://drive.google.com/file/d/0B1NXWZBKQN6ETmg2SEFOZUsxV28/view?usp=sharing

Wiresharkの帯域幅グラフは次のとおりです。

enter image description here （線はすべてのパケット、青いバーはTCPエラー）

キャプチャの私の解釈（および私は専門家ではない）から、TCP RSTフラグはサーバーではなく負荷テストソースから送信されているように見えます。したがって、何かが負荷テストサービス側の誤りです。これは、負荷テストサービスとサーバー間の何らかのネットワーク管理またはDDOS緩和の結果であると想定しても安全ですか？

ありがとう！

nginxtcphigh-loadreset
10
Erik Swan

接続リセットの原因はいくつでも存在する可能性があります。ロードテスターは、接続を開始するための利用可能なエフェメラルポートが不足している可能性があります。途中のデバイス（NATを実行しているファイアウォールなど）は、NATプールを使い果たし、提供できません。接続の送信元ポート、接続制限に達した可能性のあるロードバランサーまたはファイアウォールがエンドにありますか？また、受信トラフィックで送信元NAT）を実行すると、ポートの枯渇も発生する可能性があります。

両端からのpcapファイルが本当に必要です。あなたが探したいのは、接続の試みが送信されたがサーバーに到達せず、サーバーによってリセットされたように見えるかどうかです。その場合は、回線に沿った何かが接続をリセットする必要がありました。 NATプールの枯渇は、これらの種類の問題の一般的な原因です。

また、netstat -stはいくつかの追加情報を提供する場合があります。

1
GeorgeB

私自身の最近の同様のチューニング経験に基づいて、試してみるべきいくつかのアイデア。参照あり：

あなたはそれが静的テキストファイルだと言います。アップストリーム処理が行われている場合に備えて、明らかにドメインソケットはTCP TCポートベースの接続でのスループットを向上させます。

https://rtcamp.com/tutorials/php/fpm-sysctl-tweaking/https://engineering.gosquared.com/optimising-nginx-node-js-and-networking -for-heavy-workloads

アップストリーム終端に関係なく：

Multi_acceptとtcp_nodelayを有効にします。 http://tweaked.io/guide/nginx/

無効にするTCPスロースタート： https://stackoverflow.com/questions/17015611/disable-tcp-slow-starthttp：// www。 cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/

最適化TCP輻輳ウィンドウ（initcwnd）： http://www.nateware.com/linux-network-tuning-for-2013.html

1
JayMcTee

開いているファイルの最大数を設定するには（それが問題を引き起こしている場合）、「fs.file-max = 64000」を/etc/sysctl.confに追加する必要があります

1
Sean1e

コマンドTIME_WAITを使用してnetstat -patunl| grep TIME | wc -l状態のポートの数を確認し、net.ipv4.tcp_tw_reuseを1に変更してください。

0
fgbreel