我们的服务器有时会有90％以上的数据包丢失，但并不总是附加。 现在它完美的工作，但半小时前，它只是这个问题。
我们的服务提供商告诉我们要进入恢复系统来testing这是否是硬件问题，而不是我们这边的软件。 但是，我没有看到任何可能导致丢包的事情，特别是如果不一致的话。
在对恢复系统进行其他testing之前，有什么可以检查的吗？
我们在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
这是以太网configuration
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
在我看来，这是hetzner故障。 对于类似的情况，我一直和他们争论很久。
我们遇到了这些问题，并将其报告给托pipe公司。 答案总是一样 – “请在两个方向上附上mtr” – 即使在错误期间，他们也会这样回答。 所以我们编写了一个守护进程，每当服务器之间发生任何数据包丢失时，都会启动mtr。
如果[-z $ 1]; 然后
回声“给目标主机”
其他
主机= $ 1
而真实的; 做
丢失=`ping -c 10 $ host | grep包| awk {'print $ 6'} | sed s /％// g`
如果[$ loss -ge 1]; 然后
echo`date` >> /root/scripts/loss_measure_mtr.log
mtr -s 1500 -r -c 1000 -i 0.1 $ host >> /root/scripts/loss_measure_mtr.log
科幻
DONE
科幻
然后用这个信息他们回答：
此时在该子网中有一个传入的攻击。 在这种情况下 丢包可能发生在同一子网中的服务器上。 最好的祝福 迈克尔Straetz Hetzner Online AG 支持 90431纽伦堡/德国 电话：+49（911）234 226 54 传真：+49（911）234 226 8 977 http://www.hetzner.de
究竟发生了什么？ 我不知道，但看起来几乎一样：
太阳8月12日01:13:20 CEST 2012 主机：应用程序损失％Snt最后平均最佳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 ** 静态88-128-24-108.客户15.5％1000 3.6 3.5 3.4 4.6 0.1 主机：应用程序损失％Snt最后平均最佳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 静态88-128-24-108.客户12.8％1000 3.6 3.5 3.3 4.5 0.1 我有几十个这样的地铁。
在我看来，这是他们的基础设施问题。 注意在节点上发生了损失： hos-tr1.ex3k3.rz1.hetzner.de ， hos-tr4.juniper2.rz13.hetzner.de等等。
如果他们不解决，我可能会迁移到林德或亚马逊。
这不是一个答案，但它太长的评论，因此我张贴它作为一个答案。
我并不完全同意现有答辩人所作的评估和对这个问题的一些评论。
使用任何通过ping和traceroute使用ICMP的工具（如mtr，如果我理解它是如何工作的）的问题是，该工具正在testingpath中的每一跳如何响应ICMP通信，这意味着testing被发送到每个然后测量跳跃响应。 这不是通过path上的每一跳的path质量的真实testing，这意味着它不是通过pathtesting“真实”stream量的传输。 每跳可以select给你的基于ICMP的testing低优先级，或者可以完全放弃它，因此从一跳到下一跳的结果的变化。 如果你在第10跳（在你的第一个屏幕抓取中）有一个真实的问题，那么这个问题将会在每个连续的跳跃中进行（并累积）。 正如你可以在你的场景中看到的那样，跳数10显示了39％的数据包丢失，但是跳数11显示几乎没有数据包丢失。 如果跳10真的下降“真正的”stream量，那么问题也会出现在第11跳。 事实上，第11跳可能会显示更多的数据包丢失（第10跳丢失，第10跳和第11跳之间链路丢失以及第11跳丢失）。
你应该做的就是testing一个工具，从一端发送真正的stream量到另一端，如iperf。