如何找到延迟增加的根源？

我已经在我们办公室的几台设备上监控设置。小型访问交换机的ping响应时间通常为1-4毫秒...截至今天早上3时，该平均速度已飙升至300毫秒。

在这种情况下，人们从哪里开始寻找？我可以在交换机中观察到哪些内容以查找延迟源？

注意：这与负载无关。所有链路的带宽使用情况正常且不受影响，大多数链路利用率很低。另外-监视是报告延迟的设备的本地设置，因此此处没有WAN因素。

首先，延迟不直接与带宽相关。除了拥塞链路之外，设备会延迟数据包的原因有很多。

您是否尝试过跟踪路由？如果您正在寻找L3边界作为可疑对象，这将向您显示跃点之间的等待时间。

您可能还会检查路径中是否有任何设备占用了大量CPU / RAM。

如果这只是基于LAN，则可以做一些事情来开始尝试找出导致此问题的原因：

• Show process cpu history命令：如果CPU使用率很高，那么您需要查看引起此问题的进程，并可能通过令人反感的进程访问google。

• show debug命令：我发现的一个常见原因是人们在交换机上留下了运行调试命令的信息。常见的偏爱是将IP记帐保留在已经过度使用的设备上。使用“全部撤消调试”摆脱调试。

• 重新启动它：可能不是在白天，但是请使用“重新加载”命令在晚上或周末对它进行计时。您会惊讶于快速重启可以解决多少问题。

• 关闭中继端口 -如果它是L3交换机，我看到的另一个常见问题是使用此设备在VLAN之间进行路由的流量过多。如果可能，请暂时关闭某些中继端口，以查看这是否会减少延迟。

很高兴知道，就延迟以及在由CPU处理时，您的ping优先级较低。最好再次检查您的QoS设置，并确保没有愚蠢的错误导致这种情况，这是一个好主意，这是不太可能的。

我使用仙人掌来监视带宽，并使用openNMS来监视延迟。如果您正在监视链接到此交换机的所有设备，则可能会看到使用情况和延迟之间的必然关系。（我知道您说这不是带宽问题，但您从未如此）我已经看到低端交换机在高使用率下会下垂，这会导致大量延迟。您是否有任何“笨拙”的设备为该交换机供电，即使该交换机没有通过太多流量，也可能是导致该信号下降的原因。同样，使用仙人掌，您也许可以查询CPU使用率，并且在等待时可能会出现峰值。

如上所述，MTR或neotrace对监视情况也很有用，您可能会看到延迟从何处开始，而这可能不是此开关本身。

如果在局域网上没有发生这种情况，则可以限制“ wan port”吞吐量，这将强制执行更好的TDM。尝试最大吞吐量的80％左右，看看是否有帮助。您可能需要一周时间，具体取决于终端的数量。