我在一个星期前从UbiquityServers获得了服务器,我安装了一个简单的Apache服务器,它只是提供图像。 服务器负载很小,因为它仅仅是Amazon CloudFront背后的一个原始服务器,但是昨天它突然变得对SSH没有反应,直到我重新启动了SSH。我试图find是什么造成了这个问题我将不胜感激来自社区的任何意见。
这里有一些发现。
我注意到在接收到的组播数据包时有一个尖峰,这里是一个日志:
sar -n DEV -f sa29 | less 08:30:01 PM eth1 66.96 63.34 19.54 62.51 0.00 0.00 0.05 08:40:01 PM lo 0.07 0.07 0.01 0.01 0.00 0.00 0.00 08:40:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:40:01 PM eth1 65.05 70.51 5.63 84.70 0.00 0.00 0.02 08:50:01 PM lo 0.04 0.04 0.00 0.00 0.00 0.00 0.00 08:50:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 08:50:01 PM eth1 57.84 59.48 6.71 67.85 0.00 0.00 0.04 09:00:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 09:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:00:01 PM eth1 48.55 47.35 4.30 53.78 0.00 0.00 0.03 09:10:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 09:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:10:01 PM eth1 53.16 51.88 5.61 58.48 0.00 0.00 0.02 09:20:01 PM lo 0.04 0.04 0.00 0.00 0.00 0.00 0.00 09:20:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:20:01 PM eth1 61.80 63.91 7.75 73.46 0.00 0.00 0.05 09:30:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 09:30:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:30:01 PM eth1 54.74 55.70 5.79 63.43 0.00 0.00 0.02 09:40:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 09:40:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:40:01 PM eth1 27.83 28.57 3.17 32.59 0.00 0.00 1058754721.47 09:50:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:50:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 09:50:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142789576.69 10:00:01 PM lo 0.05 0.05 0.01 0.01 0.00 0.00 0.00 10:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:00:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2152346090.50 10:10:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 10:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:10:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142038999.87 10:20:01 PM lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:20:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:20:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2153457524.69 10:30:01 PM lo 0.01 0.01 0.00 0.00 0.00 0.00 0.00 10:30:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 10:30:01 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 2142646569.12 Average: lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 Average: eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: eth1 91.61 90.43 21.05 59.33 0.00 0.00 87333330.59 10:42:20 PM LINUX RESTART 10:50:01 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 11:00:01 PM lo 0.03 0.03 0.00 0.00 0.00 0.00 0.00 11:00:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 11:00:01 PM eth1 31.57 28.14 2.54 30.25 0.00 0.00 0.05 11:10:01 PM lo 0.11 0.11 0.01 0.01 0.00 0.00 0.00 11:10:01 PM eth0 0.00 0.00 0.00 0.00 0.00 0.00 0.00
服务器正在使用CentOS 6.我不太确定我还应该检查什么。
我只是想为此做出贡献,因为我有完全相同的问题,使用与OP相同的托pipe公司。 我们的服务器在很长一段时间(有时是几个小时)都没有响应,而且总是与疯狂的传入数据包一致。
我发现的是,我们的服务器不在私有VLAN上,并且暴露于“公共”多播和广播stream量,特别是可能针对我们IP地址的先前所有者的stream量(networking主机回收这些stream量)。 我们的IP地址曾经是一个在线游戏社区使用,所以去图。
让Ubiquity的家伙把我们放在一个专用的VLAN上立即解决了这个问题,总共80美元(一次性费用)。 当我向我的专用服务器购买此漏洞时,他们应该已经提醒过我,但他们没有。
对于Ubiquity Hosting我没什么好说的,所以我想确保logging清楚,它只是归结为我的IP容易受到UDPstream量的影响,而我的盒子不能处理10亿以上的错误UDP数据包在这样一个短的突发。
希望这可以帮助别人!