根本的な原因はおそらく同じであるため、これはおそらく 私の前の(未回答の)質問 の続きです。
Nginxとsshdを実行しているLinuxサーバーがあります。共有の100mbit/sの従量制リンク上にあります。 「ピーク時」(基本的には米国の日中)には、sftpのパフォーマンスが非常に悪くなり、接続する前にタイムアウトになることがあります。 sshは影響を受けません。 nginxを停止すると、sftpの問題がすぐに解消されるため、nginxであることがわかります。ただし、nginx自体は、これらの「エピソード」の間、本質的にゼロのレイテンシーを持っています。
これは私のサーバーの長年の問題であり、私は最近、それを完全に処理するために着手しました。昨日、アップストリーム帯域幅の不足によって引き起こされたより大きな遅延と相まって、膨大な量のhttpトラフィックが私のsftpトラフィックを混雑させているのではないかと疑い始めました。 tc
を使用して、優先順位を追加しました。
/sbin/tc qdisc add dev eth1 root handle 1: prio
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip dport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip sport 22 0xffff flowid 1:1
/sbin/tc filter add dev eth1 protocol ip parent 1: prio 1 u32 match ip protocol 1 0xff flowid 1:1
残念ながら、最初のprioでsftpパケットが蓄積しているのを見ることができますが:
class prio 1:1 parent 1:
Sent 257065020 bytes 3548504 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:2 parent 1:
Sent 291943287326 bytes 206538185 pkt (dropped 615, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
class prio 1:3 parent 1:
Sent 22399809673 bytes 15525292 pkt (dropped 2334, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
...接続時の遅延はまだ許容できません。これは、何かをsftpレイテンシーと相関させようとしているときに私が今作成したいくつかのきれいなグラフです:
これは、別の場所からのsftp遅延です。タイムアウトを25秒に設定しています。小さなファイルを接続してダウンロードするのにかかる通常の1〜2秒を超えるものは、私には受け入れられません。夜間に問題が発生し、日中にレイテンシーが再び発生する様子を確認できます。
/proc/net/sockstat
の内容。 sftpレイテンシとtcpメモリ使用量の明らかな相関関係に注意してください。それが何を意味するのか分かりません。
nginxのスタブステータスモジュールの出力。ここには何も表示されません...
netstat -tan | awk '{print $6}' | sort | uniq -c
の出力。繰り返しますが、フラットに見えます。
では、なぜtc
が機能しないのですか?ポート22の入出力を優先するのではなく、実際に帯域幅を制限する必要がありますか?または、tc
はジョブにとって間違ったツールであり、sftpのパフォーマンスが悪い本当の原因を完全に見逃していますか?
uname -a
の出力:
Linux [redacted] 3.2.0-0.bpo.2-AMD64 #1 SMP Fri Jun 29 20:42:29 UTC 2012 x86_64 GNU/Linux
でコンパイルされたmp4ストリーミングモジュールを使用してnginx1.2.2を実行しています。
2012/07/31を編集:
ewwhiteは、帯域幅の制限に近づいているのか、限界に達しているのかを尋ねました。確認したところ、100メガビットの制限とsftpの遅延の不良との間に相関関係があるようです(完全なものではありませんが)。
しかし、なぜこれらのエピソードの間、sftpトラフィック(ポート22に関連付けられている)がhttpトラフィックよりも優先されないのでしょうか。
2012/07/31#2を編集
Sftp/scp遅延データを収集しているときに、次のグラフ(追加した緑色の線)に示すようなパターンに気づきました。
2つのクラスター-「ベースライン」レイテンシーを差し引くと、約5秒と約10秒になります。また、上記のsftpレイテンシグラフで、はるかに大きなタイムスケールでそれらを非常に明確に確認できます。この5秒の数字はどこから来ていますか?
いくつかのことが私に飛び出します...
/proc/sys/kernel/random/entropy_avail
を確認してください)?例えば。あなたのnginxセッションは多くのSSLリクエストを行っていますか?これは、暗号化を使用する他のサービスに明らかな影響を与える可能性があります。sysctl.conf
チューニングパラメータがいくつかありますが(tcpウィンドウサイズ?)、sftpはそれほど効率的ではありません。 scp
はオプションですか?ファイルの大きさはどれくらいですか?/etc/hosts
内のソースIPのスタブエントリを試して、それが役立つかどうかを確認してください。したがって、互いにマスキングする際に少なくとも3つの異なる問題が発生したことがわかりました。問題を解決するために私がしたことは次のとおりです。
ポート22でICMPと着信/発信トラフィックに優先順位を付けます(上記の質問に示されているように)。これにより、sftpの応答性(例:ls
)が向上し、ピーク時の送信スループットも向上します。
Debianバックポートを介してhaveged
パッケージをインストールすることにより、エントロピー不足を解決します。これにより、 "select()
で数分間ハングする" の問題が解決されます。 ewwhite ++
_UseDNS no
_を_/etc/ssh/sshd_config
_に追加し、sshd
を再ハッシュします。これにより、ピーク時の5秒間隔でのsftp遅延が解決されます。セルゲイ・ヴラソフ++
残りの謎:
私のホストは最初に_/etc/resolv.conf
_を構成し、2つのネームサーバーをプライマリとして追加しました。これらのネームサーバーの1つ以上がピーク時(つまり、米国では日中)に過負荷になり、sftp遅延グラフで気付いた5秒間隔の遅延が発生することは理解できます。しかし、ファイルを転送するたびにsftp
がDNS逆引き参照を実行するのはなぜですか?これらは、最初の接続でリバースルックアップがタイムアウトし、最初の転送でsftp
サブシステムが何度も試行し、IPのリバースに失敗したという単純なケースでしたか?この場合、システムはセカンダリネームサーバーを試行しませんか?いずれにせよ、ISPの過負荷サーバーのプライマリとして、よく知られているパブリックネームサーバーをいくつか追加したので、この同じサーバーで実行されている他の可能なアプリケーションでは、ピーク時にDNSで問題が発生することはありません。
サーバーでエントロピーを消費しているのは何ですか?ストックnginx(静的ファイルを提供する)がRand()
を呼び出すという証拠は見つかりませんでしたが、それでもまさにそれが起こっているようです。それはファイルシステム(ext3/4)ですか、それともカーネルの別の部分が何らかの形で関係していますか?
とにかく、これは今のところ十分です。このコミュニティのおかげで、私は10年以上のUNIXWebサーバー管理で遭遇した最も厄介で永続的な問題の1つを解決することができました。