редактировать : Проблема решена. Рассматриваемые очереди использовались для пакетов управления потоком. Другой вопрос, почему драйвер igb распространял пакеты FC для их отбрасывания (и подсчета). Но решение состоит в том, что ничего не упало так, чтобы данные были потеряны.
Большое спасибо, syneticon-dj, указатель на dropwatchбыло золото!
=== исходный вопрос для дальнейшего использования ===
имеем следующую ситуацию:
Система. Рассматриваемый сервер - это dell poweredge с 4 четырехъядерными процессорами xenon, 128 ГБ ОЗУ ECC и работающий под управлением debian linux. Ядро 3.2.26.
Речь идет о специальных картах iSCSI с четырьмя интерфейсами, каждая из которых использует контроллер Intel 82576 Gigabit Ethernet.
Справочная информация: на одном из наших серверов множество NAS (Thecus N5200 и Thecus XXX) подключены с использованием iSCSI на выделенных интерфейсах 1 ГБ / с. У нас есть 5 карт по 4 порта. Файловые системы NAS подключаются напрямую, без переключения между ними.
Две недели назад нам удалось очистить четыре файловых сервера NAS и использовать их для создания raid6 с использованием на них mdadm. Использование LVM позволяет нам динамически создавать, сжимать и / или увеличивать хранилище для наших различных проектов вместо того, чтобы время от времени искать свободное место во всех наших файловых системах NAS.
Тем не менее, у нас было много переполнений практически на каждом интерфейсе, и многие пакеты были сброшены. Исследования показали, что настройки по умолчанию для сетевого стека должны быть увеличены. Я использовал sysctl, чтобы настроить все параметры до тех пор, пока больше не произойдет переполнение.
К сожалению, интерфейсы, которые используются для рейда NAS, по-прежнему отбрасывают много пакетов, но только RX.
После поиска (здесь, google, metager, intel, где угодно, везде) мы обнаружили информацию о драйверах Intel igb, которые имеют некоторые проблемы и что необходимо выполнить некоторую работу.
Поэтому я загрузил последнюю версию (igb-4.2.16), скомпилировал модуль с поддержкой LRO и отдельных очередей и установил новый модуль.
Все 20 (!) Интерфейсов, использующих этот драйвер, теперь имеют 8 очередей RxTx (непарных) и LRO включены. Линия конкретных вариантов:
options igb InterruptThrottleRate=1 RSS=0 QueuePairs=0 LRO=1
irqbalancer прекрасно распределяет очереди всех интерфейсов, и все работает отлично.
Так зачем я пишу? У нас возникла такая странная ситуация, и мы просто не можем ее объяснить:
Три из пяти интерфейсов для рейда NAS (мы добавили один запасной NAS, и рейд должен быть увеличен после того, как mdadm завершит текущую реорганизацию), демонстрируют огромное количество (миллионы!) Отбрасываемых пакетов.
Исследования с помощью ethtool теперь показывают, благодаря новым драйверам с поддержкой нескольких очередей, что каждый интерфейс массово использует одну очередь, мы предполагаем, что это будет изменение формы.
Но три используют другую очередь с миллионами входящих пакетов, которые все отбрасываются. По крайней мере, показали исследования с использованием «часов», что номера пакетов в этих очередях коррелируют с потерянными пакетами.
Мы изменили MTU на NAS и интерфейсах с 9000 до 1500, но скорость отбрасывания пакетов увеличилась, а производительность mdadm снизилась. Таким образом, это не похоже на проблему с MTU. Кроме того, в сетевом стеке есть безумное количество памяти, и это тоже не должно быть проблемой. отставания достаточно велики (фактически огромны), и мы полностью в море.
Здесь есть пример вывода:
~ # for nr in 2 3 4 5 9 ; do eth="eth1${nr}" ; echo " ==== $eth ==== " ; ethtool -S $eth | \
> grep rx_queue_._packet | grep -v " 0" ; ifconfig $eth | grep RX | grep dropped ; \
> echo "--------------" ; done
==== eth12 ====
rx_queue_0_packets: 114398096
rx_queue_2_packets: 189529879
RX packets:303928333 errors:0 dropped:114398375 overruns:0 frame:0
--------------
==== eth13 ====
rx_queue_0_packets: 103341085
rx_queue_1_packets: 163657597
rx_queue_5_packets: 52
RX packets:266998983 errors:0 dropped:103341256 overruns:0 frame:0
--------------
==== eth14 ====
rx_queue_0_packets: 106369905
rx_queue_4_packets: 164375748
RX packets:270745915 errors:0 dropped:106369904 overruns:0 frame:0
--------------
==== eth15 ====
rx_queue_0_packets: 161710572
rx_queue_1_packets: 10
rx_queue_2_packets: 10
rx_queue_3_packets: 23
rx_queue_4_packets: 10
rx_queue_5_packets: 9
rx_queue_6_packets: 81
rx_queue_7_packets: 15
RX packets:161710730 errors:0 dropped:4504 overruns:0 frame:0
--------------
==== eth19 ====
rx_queue_0_packets: 1
rx_queue_4_packets: 3687
rx_queue_7_packets: 32
RX packets:3720 errors:0 dropped:0 overruns:0 frame:0
--------------
Новый запасной диск подключен к eth15.
Как видите, никаких перерасходов и ошибок нет. А адаптеры сообщают, что ни одного пакета не сбросили. Таким образом, ядро выбрасывает данные. Но почему?
редактировать: Я забыл упомянуть, что от eth12 до eth15 все расположены на одной карте. eth19 по другому.
Кто-нибудь когда-либо был свидетелем такого странного поведения, и было ли решение, как исправить ситуацию?
И даже если нет, знает ли кто-нибудь метод, с помощью которого мы могли бы по крайней мере узнать, какой процесс занимает очереди отбрасывания?
Заранее большое спасибо!
У вас достаточно интерфейсов для создания коммутатора рабочей группы. Поскольку эта конфигурация используется не так часто и, следовательно, не тестируется так тщательно, ожидайте странностей, исходящих только от нее.
Кроме того, поскольку ваша установка довольно сложна, вам следует попытаться изолировать проблему, упростив ее. Вот что бы я сделал:
/sbin/ethtool -S <interface> чтобы узнать, связаны ли падения с проблемой ссылкиdropwatch чтобы лучше понять, можно ли увеличить другие буферы