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

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

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

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

12 голосов | спросил A L 28 J0000006Europe/Moscow 2013, 01:16:03

4 ответа


6

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

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

Вы также можете проверить, имеет ли какое-либо из устройств в пути значительное использование CPU /RAM.

ответил Mierdin 28 J0000006Europe/Moscow 2013, 01:19:04
2

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

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

ответил Blake 28 J0000006Europe/Moscow 2013, 02:57:24
2

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

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

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

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

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

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

ответил Artanix 28 J0000006Europe/Moscow 2013, 11:58:25
0

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

ответил user41897 1 FriEurope/Moscow2017-12-01T03:02:25+03:00Europe/Moscow12bEurope/MoscowFri, 01 Dec 2017 03:02:25 +0300 2017, 03:02:25

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132