Я понимаю, что это очень субъективно и зависит от ряда переменных, но мне интересно, какие шаги проходят большинство людей, когда им нужно диагностировать потерю пакетов в данной системе?
Я сетевой инженер, поэтому опишу это со своей точки зрения.
Для меня диагностика потери пакетов обычно начинается с того, что «работает не очень хорошо». Оттуда я обычно стараюсь найти комплект как можно ближе к обоим концам связи (обычно рабочая станция в офисе и где-то сервер) и пинговать как можно ближе к другому концу (в идеале «удаленная конечная точка», но иногда есть брандмауэры, через которые я не могу отправлять эхо-запросы, поэтому придется согласиться на интерфейс LAN на маршрутизаторе) и посмотреть, вижу ли я какие-либо потери.
Если я вижу потери, это обычно случай «недостаточной пропускной способности» или «связи с проблемами» где-то посередине, поэтому найдите маршрут через сеть и начните с середины, что обычно дает вам один или другой конец.
Если я не вижу потери, следующие два шага, как правило, - «отправить больше пингов» или «отправить больше пингов». Если такая сортировка не дает представления о том, в чем проблема, пора начать изучать политики QoS и статистику интерфейсов на всем пути между конечными точками.
Если ничего не найдено, пришло время поставить под сомнение ваши предположения, действительно ли вы страдаете от потери пакетов. Единственный верный способ найти это - одновременный захват на обоих концах, либо с помощью WireShark (или его эквивалента) на хостах, либо путем подключения машин-анализаторов (возможно, с использованием WireShark или аналогичных) через сетевые ответвители. Затем приходит удовольствие от сравнения двух захватов пакетов ...
Иногда то, что называют «потерей пакетов», - это просто что-то на стороне сервера, которое заметно медленнее (например, перемещение базы данных из «в той же локальной сети» в «20 мс» и использование запросов, требующих очень много между клиентской частью и базой данных).
С точки зрения системы 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).
Если приложение устанавливает свой собственный размер буфера сокета, то ему могут потребоваться изменения конфигурации. Если ваше приложение имеет жестко заданные размеры буфера сокета, пожаловаться поставщику приложения.
Лично мне не нравится разгрузка протокола на сетевые адаптеры (контрольная сумма, разгрузка сегментации, большая разгрузка приема), поскольку это, кажется, вызывает больше проблем, чем того стоит. Поиграйте с этими настройками, используя ethtool -K может быть стоит попробовать.
Посмотрите варианты модуля для вашей сетевой карты (modinfo <drivername>), так как вам может потребоваться изменить некоторые функции. Приведу один пример, с которым я столкнулся, использование Intel Flow Director в системе, которая обрабатывает один большой поток TCP, вероятно, нанесет ущерб эффективности этого потока, поэтому отключите FDir.
Помимо этого, вы вручную настраиваете эту конкретную систему для ее конкретной рабочей нагрузки, что, как я полагаю, выходит за рамки вашего вопроса.
Я начну с использования инструмента захвата пакетов, такого как wirehark (в Windows) и tcpdump (в терминале Linux).
Я также проверю конфигурацию брандмауэра (брандмауэр хоста, а также сетевой брандмауэр).
Изолируйте, а затем устраните.
Найдите наименьшее подмножество путей с проблемой. Сделайте это путем тестирования различных комбинаций и / или обработки пользовательских отчетов. Не забывайте учитывать время в уравнении. Может быть, это всего лишь потеря пакетов для всего трафика в определенной сети, а может быть, страдают только беспроводные клиенты. Учитывать разные типы трафика (ограничение скорости на пинги). Найдите самый надежный и легко повторяемый способ проверить это.
Затем устраните потенциальные причины. Уменьшите трафик на каналах (временно), удалите источники помех из спектра, отключите определенных клиентов. В конце концов вы найдете источник проблемы.
Иногда вы можете использовать ярлыки, просматривая дампы пакетов или делая предположения (это всегда битторент). Также скажите своему профессору, что serverfault - это здорово.
Пинги могут не показывать потерю пакетов, если вы не отправите большие эхо-запросы! У меня была потеря пакетов в моей сети, которая была невидимой, пока я не увеличил размер пакета ping.
Для окон:
ping -n 30 -l <largevalue> <target>
Для largevalue Я использовал 40960 (пакет 40k)
Для target Я использовал первые несколько IP-адресов из tracert google.com
(который был моим маршрутизатором и кабельным модемом). Одно из устройств ниже по цепочке имело ужасную потерю пакетов (> 60%) для больших пакетов, но 0% для маленьких. Я исправил это, перезапустив его, но это также может быть кабель или что-то внутреннее, которое нужно заменить.