バーストでの非常に高いパケット損失
サーバーで90％以上のパケット損失が発生することがありますが、必ずしも追加されるとは限りません。今は完璧に動作しますが、30分前にはその問題がありました。
私たちのサービスプロバイダーは、これが本当にハードウェアの問題であり、私たちの側のソフトウェアではないかどうかをテストするために、リカバリシステムに入るように私たちに言っています。ただし、特に一貫性がない場合は、パケット損失を引き起こす可能性のあるものは何もありません。
リカバリシステムで他のテストを行う前に確認できることはありますか？
Hetzner.deに専用サーバーがあります。 100MBitイーサネットに接続されています。サーバープロバイダーは、ハードウェアのチェックを続行する前にソフトウェアをチェックすることを望んでいるため、ハードウェア側では何も変更しようとしませんでした。
これが私が作ったmtrレポートです。そのレポートの間に、3回のパケット損失が発生し、残りの時間はサーバーに到達可能でした。
クライアントからサーバーへ
Host: mbp Loss% Snt Last Avg Best Wrst StDev
1.|-- 10.0.1.1 0.0% 1000 0.4 0.2 0.2 3.4 0.2
2.|-- 10.0.1.1 0.3% 1000 27.5 29.7 5.9 237.3 34.6
3.|-- 10.170.172.121 0.4% 1000 17.2 41.9 7.2 334.1 44.2
4.|-- 216.113.123.158 1.4% 1000 44.4 58.6 10.6 299.6 49.2
5.|-- 216.113.123.194 1.1% 1000 36.6 72.9 19.4 330.7 48.1
6.|-- paix-nyc.init7.net 0.7% 1000 57.1 75.8 18.4 313.8 49.1
7.|-- r1lon1.core.init7.net 1.4% 1000 199.8 150.9 87.1 373.7 56.4
8.|-- r1fra1.core.init7.net 0.6% 1000 244.2 150.1 98.6 438.6 53.6
9.|-- gw-hetzner.init7.net 1.4% 1000 175.3 140.6 100.5 397.2 49.7
10.|-- hos-bb2.juniper2.rz16.het 39.0% 1000 120.0 136.7 103.5 362.6 44.3
11.|-- hos-tr4.ex3k13.rz16.hetzn 0.8% 1000 145.4 132.2 106.8 393.3 36.9
12.|-- static.98.43.9.5.clients. 39.8% 1000 116.0 131.5 106.1 371.8 34.4
サーバーからクライアントへ
Host: thetransitapp Loss% Snt Last Avg Best Wrst StDev
1. static.97.43.9.5.clients.you 29.0% 1000 7.2 7.4 0.9 24.9 1.9
2. hos-tr1.juniper1.rz16.hetzne 38.7% 1000 6.1 9.6 0.2 78.8 7.6
3. hos-bb2.juniper4.ffm.hetzner 36.2% 1000 11.8 11.4 5.8 29.0 1.5
4. r1fra1.core.init7.net 38.1% 1000 12.4 13.9 5.5 22.9 3.9
5. r1lon1.core.init7.net 36.3% 1000 23.5 26.5 17.6 37.6 4.4
6. r1nyc1.core.init7.net 35.5% 1000 92.3 93.8 86.1 103.0 3.7
7. paix-ny.ia-unyc-bb05.vtl.net 35.5% 1000 95.5 96.4 87.6 134.7 5.3
8. 216.113.123.169 36.3% 1000 101.5 102.0 94.4 124.9 3.6
9. 216.113.124.42 34.7% 1000 113.1 107.7 96.7 117.6 3.6
10. 216.113.123.157 37.5% 999 106.5 107.4 101.5 115.0 1.5
11. ??? 100.0 999 0.0 0.0 0.0 0.0 0.0
12. modemcable004.103-176-173.mc 36.7% 999 111.2 147.9 107.2 342.0 48.3
これがイーサネット構成です
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00000033 (51)
Link detected: yes
eth0のifconfig：
eth0 Link encap:Ethernet HWaddr c8:60:00:bd:2f:9d
inet addr:5.9.43.98 Bcast:5.9.43.127 Mask:255.255.255.224
inet6 addr: fe80::ca60:ff:febd:2f9d/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3521 errors:0 dropped:0 overruns:0 frame:0
TX packets:2117 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2882770 (2.7 MiB) TX bytes:910907 (889.5 KiB)
Interrupt:30 Base address:0x8000
私の意見では、それはヘッツナーのせいです。私は非常に長い間、同様の事件について彼らと議論してきました。
私たちはそれらの問題を抱えていて、それをホスティング会社に報告していました。答えはいつも同じでした-「両方向にmtrを取り付けてください」-彼らは故障中でもそのように答えるでしょう。そのため、サーバー間でパケット損失が発生するたびにmtrを起動するデーモンを作成しました。
if [-z $ 1]; then
echo "Give target Host"
else
Host = $ 1
while true; do
loss = `ping -c 10 $ Host | grepパケット| awk {'print $ 6'} | sed s /％// g`
if [$ loss -ge 1]; then
echo `date` >>/root/scripts/loss_measure_mtr.log
mtr-s 1500 -r -c 1000 -i 0.1 $ Host >> /root/scripts/loss_measure_mtr.log
fi
完了
fi
それからこの情報で彼らは答えました：
この時点で、サブネットに着信攻撃がありました。この場合、 同じサブネット内のサーバーでパケットロスが発生する可能性があります。 よろしくお願いします Michael Straetz Hetzner Online AG サポート 90431ニュルンベルク/ドイツ 電話：+49（911）234 226 54 ファックス：+49（ 911）234 226 8 977 http://www.hetzner.de
正確には何が起こっているのですか？私は知りませんが、それはほとんど同じに見えます：
Sun Aug 12 01:13:20 CEST 2012 ホスト：app Loss％Snt Last Avg Best Wrst StDev 1。94.1％1000 0.2 0.2 0.1 0.4 0.1 2. static.1.24.24.46.clients.you 0.0％1000 3.0 1.9 0.7 19.4 1.5 3。hos-tr4.juniper2.rz13.hetzne 9.4％1000 0.6 1.9 0.4 133.2 8.0 4 .hos-bb2.juniper1.rz1.hetzner 5.4％1000 38.6 7.1 3.0 112.9 11.5 5。hos-tr1.ex3k3.rz1.hetzner.de 10.9％1000 4.4 5.1 3.6 23.6 1.8 ** 6. static.88-128-24-108.clients 15.5％1000 3.6 3.5 3.4 4.6 0.1 ホスト：app Loss％Snt Last Avg Best Wrst StDev 1。94.5％1000 0.2 0.2 0.1 0.6 0.1 2。static.1.24.24.46.clients.you 0.0％1000 1.2 1.9 0.7 19.3 1.6 3。hos-tr4.juniper2.rz13.hetzne 9.3％1000 0.6 1.8 0.4 136.8 7.9 4。hos-bb2.juniper1.rz1.hetzner 2.7％1000 3.3 7.0 3.0 113.1 11.5 5。hos-tr1.ex3k3.rz1.hetzner.de 8.5％1000 7.0 5.1 3.6 26.8 2.0 6。static.88-128-24-108.clients 12.8 ％1000 3.6 3.5 3.3 4.5 0.1 このようなmtrが数十あります。
私の意見では、それは彼らのインフラの問題です。ノードで損失が発生していることに注意してください：hos-tr1.ex3k3.rz1.hetzner.de、hos-tr4.juniper2.rz13.hetzner.deなど。
それが修正されない場合は、おそらくlinodeまたはAmazonに移行します。
これは答えではありませんが、コメントするには長すぎるので、答えとして投稿します。
私は、既存の回答者で行われた評価とこの質問に対するコメントのいくつかに完全には同意しません。
Pingとtracerouteを介してICMPを使用するツール（動作を理解している場合はmtrなど）を使用する場合の問題は、そのツールがパス内の各ホップがICMPトラフィックにどのように応答するかをテストしていることです。つまり、テストはそれぞれに送信されます。ホップしてから、そのホップ応答を測定します。これは、パス内の各ホップを介したパスの品質の真のテストではありません。つまり、パスを介した「実際の」トラフィックの送信をテストしていません。各ホップは、ICMPベースのテストに低い優先度を与えることを選択する場合もあれば、完全にドロップする場合もあるため、ホップごとに結果が異なる場合があります。ホップ10（最初のスクリーングラブ）で真の問題が発生した場合、その問題は連続する各ホップで実行されます（累積されます）。シーングラブでわかるように、ホップ10は39％のパケット損失を示していますが、ホップ11はほとんどパケット損失を示していません。ホップ10が実際に「実際の」トラフィックをドロップしている場合、問題はホップ11でも発生します。実際、ホップ11はおそらくより多くのパケット損失を示します（ホップ10での損失、ホップ10と11の間のリンクでの損失、およびホップ11での損失の累積）。
実行する必要があるのは、iperfのように、実際のトラフィックを一方の端からもう一方の端に送信するツールを使用してテストすることです。