☰

ping 响应时间

tag-icon • tag-icon linux ping
ping 响应时间

我有两个网站托管在两个不同的数据中心。最近其中一个网站变得非常慢。应用程序服务器到数据库服务器的 ping 响应不够快。我该如何调查这个问题？

On fast server:
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.243/0.279/0.502/0.074 ms

On slow server:
21 packets transmitted, 21 received, 0% packet loss, time 20011ms
rtt min/avg/max/mdev = 1.131/1.816/3.584/0.560 ms

tracert 命令显示以下内容：

On fast server:
tracert db
traceroute to db (xxx.xxx.100.101), 30 hops max, 40 byte packets
 1  db (xxx.xxx.100.101)  0.552 ms  0.530 ms  0.527 ms

 On slow server:
tracert xxx.16.55.140
traceroute to xxx.16.55.140 (xxx.16.55.140), 30 hops max, 40 byte packets
 1  xxx.16.55.140 (xxx.16.55.140)  1.859 ms  1.845 ms  1.842 ms

答案1

执行从 Web 服务器到数据库服务器的 pathping，查看报告的减速位置。然后，通过执行从数据库服务器到 Web 前端的 pathping 进行确认。使用节点的 IP 地址，而不是 DNS 名称。正如 Womble 指出的那样，这可能是 rDNS 减速。

仅供参考，pathping 与 tracert 类似，可以根据网络拥塞情况，仅根据数据包可能以某种方式向前路由和向后路由的方式提供欺骗性的路径信息。此外，转发路径不能保证随着每次增加跳数而相同。不过，这些是无关紧要的话题。继续……

一旦确定了速度变慢的位置，您就可以继续进行故障排除。如果终端节点负载过重或配置不当，则可能是终端节点本身导致速度变慢。如果您发现速度变慢的节点是什么，请使用正确的信息更新您的问题。

答案2

您可以使用 traceroute 来查看路径上是否存在导致所有速度变慢的点。

答案3

使用Traceroute（mtr甚至更好）跟踪两台机器之间的路径，寻找增加大量延迟的特定跳数。一旦确定了位置，您就可以查找原因（检查相关链接两侧的端口统计信息，看看是否存在排队或其他问题）；您没有丢包（好吧，丢包数量不是太多——21 次 ping 并不具有统计意义），因此您大概任何地方都不会溢出缓冲区。

但是，对于“较慢”的链接，您仍然只会看到 1.8ms 的延迟，这在任何类型的 WAN 链接中都非常出色。除非您正在做某事难以置信对延迟敏感（例如高速交易），我很难想象这在任何有意义的意义上怎么会是“非常慢”。

答案4

您在问题中说网站变慢了，然后询问 ping 时间。网站变慢是否可能是由于其他原因？

如果你在两个不同的数据中心托管两个网站，并且只有一个数据库，那么带宽两个数据中心之间的差异可能是限制因素。

可能值得检查一下每次查询从数据库中提取了多少数据。数据库查询返回 10MB 数据，而脚本语言会解析/破坏/丢弃数据，直到只剩下几 KB 数据要发送给用户，这种情况并不罕见。很多人即使只需要一个字段也会使用“SELECT *”。还值得检查一下数据库端口上总共有多少流量。如果您与其他数据中心的链接只有 10Mb，而您甚至要提取 1MB 的查询，也需要将近一秒钟才能到达。

如果您的问题实际上是延迟而不是带宽，那么使用持久连接会有所帮助，因为它可以避免为每个查询建立全新的 tcp 连接。在第二个数据中心设置从属只读数据库也会有所帮助，因为只读查询可以在本地完成。

相关内容