Как найти источник повышенной задержки?

У меня есть настройки мониторинга на нескольких устройствах в нашем офисе. Время отклика ping для небольших коммутаторов доступа обычно составляет 1-4 мс ... По состоянию на 3 утра сегодня утром это в среднем достигло 300 мс.

Где можно начать искать в такой ситуации? Какие вещи я могу наблюдать в коммутаторе, чтобы найти источник задержки?

ПРИМЕЧАНИЕ. Это не связано с нагрузкой. Использование полосы пропускания для всех каналов является нормальным и незатронутым, большинство ссылок используются недостаточно. Также - мониторинг является локальным для устройств, сообщающих о задержке, поэтому здесь нет фактора WAN.

Во-первых, задержка напрямую не связана с пропускной способностью. Существует много причин, по которым устройство задерживает пакет, отличный от перегруженного канала.

Вы пытались найти трассировку? Это покажет вам задержку между прыжками, если вы ищете в качестве подозреваемого границу L3.

Вы также можете проверить, имеет ли какое-либо из устройств в пути значительную загрузку ЦП / ОЗУ.

если это только на основе локальной сети, есть несколько вещей, которые вы можете сделать, чтобы начать, чтобы попытаться выяснить, что вызывает это:

• Команда show process cpu history : если загрузка процессора очень высока, вам нужно посмотреть, какой процесс вызывает это, и, возможно, поразить Google оскорбительным процессом.

• Команда show debug : часто встречающаяся причина - люди, оставляющие команды отладки на коммутаторе. Распространенным фаворитом был учет IP-адресов на устройствах, которые уже были перегружены. Используйте "undebug all", чтобы избавиться от отладок.

• Дайте перезагрузку : возможно, не в течение дня, но используйте команду «reload in» для определения времени ночью или в выходные дни. Вы будете удивлены, сколько проблем может решить быстрая перезагрузка.

• закрытые магистральные порты - если это коммутатор L3, я обнаружил еще одну распространенную проблему - слишком большой трафик, использующий это устройство для маршрутизации между VLAN. Если возможно, временно закройте некоторые магистральные порты, чтобы проверить, не уменьшает ли это время ожидания.

Полезно осознавать, что ваши эхо-запросы имеют низкий приоритет в отношении задержки, а также при обработке процессором. Также может быть хорошей идеей перепроверить настройки QoS и убедиться, что нет глупых ошибок, вызывающих это, насколько это маловероятно.

Я использую cacti для мониторинга пропускной способности и openNMS для мониторинга задержки. Если вы отслеживаете все устройства, связанные с этим коммутатором, вы можете увидеть следствие между использованием и задержкой. (я знаю, что вы сказали, что это не проблема пропускной способности, но вы никогда этого не делали) Я видел, как низкокачественные коммутаторы провисают при интенсивном использовании, что приводит к большой задержке. Есть ли у вас какие-нибудь «тупые» устройства, питающие этот коммутатор, которые могут быть источником провисания, даже если этот коммутатор не пропускает много трафика. Также с помощью cacti вы можете опрашивать загрузку ЦП, и вы можете увидеть всплеск во время задержки.

Как упомянуто выше, MTR или neotrace также полезны, чтобы следить за ситуацией, и вы можете увидеть, где начинается задержка, которая может не являться этим переключателем.

Если этого не происходит в локальной сети, вы можете ограничить пропускную способность "wan port", это приведет к улучшению TDM. Попробуйте что-то около 80% вашей максимальной пропускной способности и посмотрите, поможет ли это. Возможно, вам придется настроить в зависимости от количества терминалов.