Как вы диагностируете потерю пакетов?

Я понимаю, что это очень субъективно и зависит от ряда переменных, но мне интересно, какие шаги проходят большинство людей, когда им нужно диагностировать потерю пакетов в данной системе?

22 голоса | спросил KushalP 30 22010vEurope/Moscow11bEurope/MoscowTue, 30 Nov 2010 15:45:33 +0300 2010, 15:45:33

4 ответа


25

Я инженер сети, поэтому я опишу это с моей точки зрения.

Для меня диагностирование потери пакетов обычно начинается с того, что «это не очень хорошо работает». Оттуда я обычно пытаюсь найти набор как можно ближе к обоим концам связи (обычно это рабочая станция в офисе и где-то на сервере) и пинг как можно ближе к другому концу (в идеале «удаленная конечная точка», но иногда есть брандмауэры, на которые я не могу отправить пинги, так что вам придется соглашаться на интерфейс LAN на маршрутизаторе) и посмотреть, не вижу ли я каких-либо потерь.

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

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

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

Иногда, что объясняется как «потеря пакетов», просто что-то на стороне сервера заметно медленнее (например, перемещение базы данных из «в той же локальной сети» на «20 мс») и использование запросов, требующих ужасная много назад и вперед между интерфейсом и базой данных).

ответил Vatine 30 22010vEurope/Moscow11bEurope/MoscowTue, 30 Nov 2010 17:03:22 +0300 2010, 17:03:22
6

С точки зрения системы Linux я сначала рассмотрю потерю пакетов в сетевом интерфейсе с помощью ethtool -S ethX.

Большую часть времени, увеличивая кольцевой буфер с помощью ethtool -G ethX rx VALUE, решает это.

Иногда прерывания не балансируются, потому что системе не хватает службы irqbalance, поэтому смотрите chkconfig (EL) или update-rc (Debuntu), чтобы узнать, работает ли эта служба. Вы можете сказать, не прерываются ли прерывания, потому что /proc/interrupts будет показывать только Core 0, обслуживающий все каналы IRQ.

В противном случае вам может потребоваться увеличить net.core.netdev_max_backlog, если система пропускает более нескольких гигабайт трафика, а может быть net.core.netdev_budget

Если это не сработает, вы можете настроить значения слияния прерываний с помощью ethtool -C.

Если на сетевом интерфейсе нет пакетов, посмотрите netstat -s и посмотрите, есть ли капли в буферах сокетов, эти будут представлены со статистикой типа «pruned from receive queue» и «dropped from out-of-order queue».

Вы можете попробовать увеличить стандартные и максимальные буферы сокетов для соответствующего протокола (например: net.ipv4.tcp_rmem для TCP).

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

Лично мне не нравится разгрузка протоколов на NIC (контрольная сумма, разгрузка сегментации, большая выгрузка), поскольку это, по-видимому, вызывает больше проблем, чем того стоит. Воспроизведение с этими настройками с помощью ethtool -K может стоить выстрела.

Посмотрите параметры модуля для вашей сетевой платы (modinfo <drivername>), так как вам может потребоваться изменить некоторые функции. Чтобы привести один из примеров, с которыми я столкнулся, использование Intel Flow Director в системе, которая обрабатывает один большой поток TCP, вероятно, повредит эффективности этого потока, поэтому выключите FDir.

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

ответил suprjami 24 J000000Thursday14 2014, 16:29:07
5

Я начну с использования инструмента захвата пакетов, такого как: wireshark (в Windows) и tcpdump (на терминале Linux).

Я также проверю конфигурацию брандмауэра (брандмауэр хоста, а также сетевой брандмауэр).

ответил Khaled 30 22010vEurope/Moscow11bEurope/MoscowTue, 30 Nov 2010 15:48:24 +0300 2010, 15:48:24
3

Изолировать, а затем устранить.

Найти наименьшее подмножество путей с проблемой. Сделайте это, проверив различные комбинации и /или отменив отчеты пользователей. Не забывайте учитывать время в экваторе. Может быть, это всего лишь потеря пакетов во всем трафике в определенной сети, или, может быть, только беспроводные клиенты страдают. Учитывайте различные типы трафика (ограничение скорости на пингах). Найдите наиболее надежный и легко повторяемый способ его протестировать.

Затем устраните потенциальные причины. Сократите трафик на ссылках (временно), удалите источники помех из спектра, отключите определенные клиенты. В конце концов вы найдете источник проблемы.

Иногда вы можете использовать ярлыки, просматривая пакеты дампов или принимайте догадки (это всегда битторен). Кроме того, скажите, что ваш сервер serverfault замечательный.

ответил Joris 30 22010vEurope/Moscow11bEurope/MoscowTue, 30 Nov 2010 17:28:25 +0300 2010, 17:28: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