Вы здесь

Главная › Форум › Gentoo Linux › Ядро Linux и поддержка оборудования

e1000e периодические подвисания

20 ноября, 2012 - 18:15 — boroda

x86_64. Обновил ядро годовалой давности 3.0.6 до 3.5.7. Столкнулся с проблемой, что при нагрузке в 600pps и 1Mbit/s пару раз в минуту по 3-4 секунды сервер переставал принимать/отправлять пакеты. При этом работа системы не тормозилась - весь софт продолжал работать, физическая консоль не замирала (в сравнении с ssh).

В результате выяснил, что дело в драйвере сетевой карты - e1000e:

01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

Параметр InterruptThrottleRate по умолчанию стоит в режиме dynamic conservative. Временно решил проблему выставив фиксированное количество прерываний - 3000. Днем нагрузка выросла до 8000pps, а load average поднялся до 0,60 - 1,00. До обновления ядра при аналогичной нагрузке load average был не выше 0,10-0,20.

Сравнил дефолтные параметры драйвера от ядра 3.0.6 с 3.5.7 - идетнично.

dmesg до:

e1000e: Intel(R) PRO/1000 Network Driver - 1.3.10-k2
e1000e: Copyright(c) 1999 - 2011 Intel Corporation.
e1000e 0000:01:00.0: Disabling ASPM L0s
e1000e 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
e1000e 0000:01:00.0: setting latency timer to 64
e1000e 0000:01:00.0: irq 48 for MSI/MSI-X
e1000e 0000:01:00.0: irq 49 for MSI/MSI-X
e1000e 0000:01:00.0: irq 50 for MSI/MSI-X
e1000e 0000:01:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:30:48:f9:62:96
e1000e 0000:01:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:01:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-0FF
e1000e 0000:02:00.0: Disabling ASPM L0s
e1000e 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
e1000e 0000:02:00.0: setting latency timer to 64
e1000e 0000:02:00.0: irq 51 for MSI/MSI-X
e1000e 0000:02:00.0: irq 52 for MSI/MSI-X
e1000e 0000:02:00.0: irq 53 for MSI/MSI-X
e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:30:48:f9:62:97
e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-0FF

dmesg после:

e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:01:00.0: Disabling ASPM L0s L1
e1000e 0000:01:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:01:00.0: irq 48 for MSI/MSI-X
e1000e 0000:01:00.0: irq 49 for MSI/MSI-X
e1000e 0000:01:00.0: irq 50 for MSI/MSI-X
e1000e 0000:01:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:30:48:f9:62:96
e1000e 0000:01:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:01:00.0: eth0: MAC: 3, PHY: 8, PBA No: 0101FF-0FF
e1000e 0000:02:00.0: Disabling ASPM L0s L1
e1000e 0000:02:00.0: (unregistered net_device): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e 0000:02:00.0: irq 51 for MSI/MSI-X
e1000e 0000:02:00.0: irq 52 for MSI/MSI-X
e1000e 0000:02:00.0: irq 53 for MSI/MSI-X
e1000e 0000:02:00.0: eth1: (PCI Express:2.5GT/s:Width x1) 00:30:48:f9:62:97
e1000e 0000:02:00.0: eth1: Intel(R) PRO/1000 Network Connection
e1000e 0000:02:00.0: eth1: MAC: 3, PHY: 8, PBA No: 0101FF-0FF

Если кто-то сталкивался с этой проблемой, подскажите, как ее решить?

Судя по форумам с проблема не очень популярна, конкретных решений или объяснений найти не удалось.

Форум: 
Ядро Linux и поддержка оборудования
20 ноября, 2012 - 19:26 — _passer

Проверьте ваш ли это случай:
http://sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/

Кроме того можно попробовать использовать не ядренный модуль, а какой-то из этих:
http://sourceforge.net/projects/e1000/files/e1000e%20stable/

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

21 ноября, 2012 - 01:27 — boroda

EEPROM на моей карте требовал фикса. Проверил под тестом на 40Мбит/с и 7000pps - проблема не проявилась, la поднялся только до 0,20. Посмотрим, что будет завтра под рабочей нагрузкой.

Огромное спасибо!

21 ноября, 2012 - 13:09 — boroda

Жаль, но дело не в EEPROM или не только в нем. Ночью попробую поставить новую версию драйвера. Удивительно, что искуственная нагрузка не вызвала проблему, которая проявилась при более низкой рабочей нагрузке. Разница в размерах пакетов и в том, что в рабочем варианте они приходят с разных IP на разные порты. В обоих случаях - это 99% UDP пакеты.

Есть еще один сервер со старым ядром и аналогичной сетевой картой - работает с такой же нагрузкой и практически ее не замечает. Будет возможность сравнивать настройки.

Нашел интересную информацию: http://rajven.ru/articles/optimizacija_nastroek_drajverov_dlja_kart_intel/index.html. Вдруг, кому-то будет полезно.

21 ноября, 2012 - 14:08 — _passer

У меня такие карты лопатят по 500-700М, в пиках до 800М. Очереди прибиты к ядрам процессора, подобран размер кольцевого буфера и работает себе. Проблем нет.

Относительно ссылки по I/OAT DMA - давно включено, и т.к. конфиг ядра давно уже определен, то об этом я уже успел забыть.

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

22 ноября, 2012 - 15:06 — boroda

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

Прошлой ночью пробовал обновить драйвер e1000e до 2.1.4. Не помогло. Решил откатиться до последнего ядра ветки 3.0 - 3.0.35. Проблема стала немного другой - сеть работает без потери пакетов, но la может подпрыгивать до 3.00 без изменений в нагрузке и потом сразу опускаться до 0.50.

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

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

22 ноября, 2012 - 16:10 — _passer

С помощью smp_affinity таки стоит прибить очереди к ядрам конкретным. Определенно не лишнее и полезное.

Покажите вывод профайлера и top'а. Уж больно интересно что там у вас творится.

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

7 декабря, 2012 - 12:13 — gebs

при таких нагрузках - это бесполезное занятие. Я бы поигрался с ethtool, потом бы собрал модулем свежий драйвер, потом бы поменял сетевухи.

23 ноября, 2012 - 12:13 — boroda

Ночью откатился до ранее собранного ядра 3.0.6. Нагрузка есть, но при этом ни единого намека, что сервер напрягается - la: 0.01-0.05. При этом картина с IRQ не изменилась. Каждое из устройств осблуживается только каким-то одним ядром

Понятно, что сейчас в top'е все по нолям. Буду на следующей неделе продолжать эксперименты (на выходных нет нагрузки). Подскажите, что за профайлер? Никогда ранее не сталкивался с его использованием.

Мысли вслух.

Есть предположение, что нагрузка вызвана нестыковкой софта и версии ядра, так как при тестировании iperf'ом la не сильно поднималась, а при рабочей нагрузке - гораздо выше.

Прошелся по бОльшему количеству серверов. Выявил закономерность - если процессор из семейства Xeon'ов, то IRQ висят на одном из ядер; если процессор Core2 Duo / Core i, то прерывания (soft/hard) распределяются по всем ядрам для каждого из устройств.

Xeon:

           CPU0       CPU1       CPU2       CPU3       
  0:         25          0          0   21249643   IO-APIC-edge      timer
  1:          0          0          0          8   IO-APIC-edge      i8042
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          0          0          0        312   IO-APIC-edge      i8042
 16:          0          0      90433          0   IO-APIC-fasteoi   3w-9xxx, uhci_hcd:usb3
 18:          2          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb8
 19:          0         45          0          0   IO-APIC-fasteoi   uhci_hcd:usb5, uhci_hcd:usb7
 21:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4
 23:         71          0          0          0   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
 40:          0          0   42630877          0   PCI-MSI-edge      eth0-rx-0
 41:          0          0   24345447          0   PCI-MSI-edge      eth0-tx-0
 42:          0          0          0          2   PCI-MSI-edge      eth0
 43:          0          0          0       9785   PCI-MSI-edge      eth1-rx-0
 44:          6          0          0          0   PCI-MSI-edge      eth1-tx-0
 45:          4          0          0          0   PCI-MSI-edge      eth1
 46:          0          3          0          0   PCI-MSI-edge      ioat-msix
 47:          0          0          3          0   PCI-MSI-edge      ioat-msix
 48:          0          0          3          0   PCI-MSI-edge      ioat-msix
 49:          0          0          0          3   PCI-MSI-edge      ioat-msix
 50:          0          0          0          3   PCI-MSI-edge      ioat-msix
 51:          3          0          0          0   PCI-MSI-edge      ioat-msix
 52:          3          0          0          0   PCI-MSI-edge      ioat-msix
 53:          0          3          0          0   PCI-MSI-edge      ioat-msix
NMI:          0          0          0          0   Non-maskable interrupts
LOC:    2830533    2522428   20722221     163311   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES:   10486222    9055032   12068873    4958705   Rescheduling interrupts
CAL:       3421       3870        629       4715   Function call interrupts
TLB:       4128       5294       8499       6027   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:         67         67         67         67   Machine check polls
ERR:          0
MIS:          0

Core i3:

           CPU0       CPU1       CPU2       CPU3       
  0:      24831      24735      24751      24531   IO-APIC-edge      timer
  1:          1          0          1          0   IO-APIC-edge      i8042
  8:         21         20         22         28   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          1          1          0          2   IO-APIC-edge      i8042
 16: 3215925405 3216053736 3216036420 3215876740   IO-APIC-fasteoi   wanpipe1, wanpipe2, wanpipe3, wanpipe4, wanpipe5, wanpipe6, wanpipe7, wanpipe8
 18:   10002151    9994339    9995978   10006603   IO-APIC-fasteoi   aacraid
 23:          6          7          9          8   IO-APIC-fasteoi   ehci_hcd:usb1
 44:  276942385  277505474  277161627  277216417   PCI-MSI-edge      eth0-rx-0
 45:  270238104  269760485  269930507  270269317   PCI-MSI-edge      eth0-tx-0
 46:          1          1          0          0   PCI-MSI-edge      eth0
 47:    6312831    6667109    6383354    6721991   PCI-MSI-edge      eth1-rx-0
 48:          3          0          2          1   PCI-MSI-edge      eth1-tx-0
 49:          1          0          1          0   PCI-MSI-edge      eth1
NMI:          0          0          0          0   Non-maskable interrupts
LOC: 1830579907 1791101150 1444787950 1360274324   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES: 1025728474  999462717 2564735034 1866413931   Rescheduling interrupts
CAL:     972546     957182    5848764    6485215   Function call interrupts
TLB:     416727     387550     414634     356198   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:      98814      98814      98814      98814   Machine check polls
ERR:          0
MIS:          0

23 ноября, 2012 - 19:20 — _passer

Ваши мысли не особо подтверждаются практикой: имею на хозяйстве кучу Xeon X3440, E5420, E5507, E3-1220 и правда, только один i5. На всех ксеонах по-умолчанию прерывания от устройств размазываются по всем ядрам.

P.S. oprofile - установите и проследите, что у вас создает такую нагрузку.

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

26 ноября, 2012 - 11:36 — boroda

Что тогда может мешать прерываниям размазываться по ядрам? На второй машине с Core i3 работает ядро с точь-в-точь таким же конфигом и прерывания размазываются. Это как бы факультативный вопрос, ибо на старом ядре сервер прекрасно работает, хотя прерывания не размазываются.

С oprofile разберусь, что к чему.

Флудить не буду, как разберусь или появятся вопросы - отпишусь.

3 декабря, 2012 - 14:33 — boroda

Результаты не впечатляют. Перечитал много форумов и статей. Определенно успешного рецепта не нашел - кому-то, что-то помогает путем проб и ошибок. Мой путь привел к следующим выводам:

1. IRQ не распределяются по ядрам в соответствии с алгоритмом round-robin, так как это платформенно-зависимая "фича". И если материнская плата или BIOS не желают того делать в конкретной комплектации, то хоть тресни - оно не заработает. Вместо этого и придуман smp_affinity, чтобы хоть как-то распределить нагрузку по ядрам. В этом плане хорошо описано в книге "Understanding the Linux Kernel" на стр. 159 "IRQ distribution in multiprocessor systems":

Цитата:
Unfortunately, in some cases the hardware fails to distribute interrupts among microprocessors in a fair way...

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

2. OProfile - 60% vmlinux, 20% сами приложения, 9% glibc, 7% e1000e, остальное размазано по частям менее 1%.

3. Непосредственно по проблеме сетевой карты. Выявлено, что в моем случае проблема возникает при изменении нагрузки, как в сторону повышения, так и в сторону понижения. В эти периоды наблюдается всплеск la и использование CPU %system. Путем экспериментов удалось собрать ядро, когда эти всплески происходят в пределах разумного и "условно" не мешают работе сервера.

Во время экспериментов попадались конфигурации ядра, когда la не давал всплесков, но постоянно наблюдались замирания работы сетевой карты до 2 сек. Причем снифер на этом же сервере показывал, что в этот момент пакеты не передавались, а после задержки выплевывались все накопленные. В это время сервер не подвисал, и консоль (KVM) продолжала отвечать, часы тикали.

Так же на результаты тестов влияли настройки BIOS. Например, отключение "Hardware Prefetcher" приводило к снижению la, но при этом возникали потери пакетов. Отключение управления питанием в BIOS приводило к первоначальной ситуации. Как я понимаю, в этом случае ОС не знала о том, что питанием устройств и процессора можно управлять, а BIOS продолжал это делать сам.

Попытки выключить IPMI через BIOS ни к чему не приводили, а сам IPMI продолжал работать, словно ему наплевать на настройки BIOS.

Всякие советы на форумах по поводу отключения acpi считаю бредовыми, ибо в этом случае система лишается многопроцессорности - остается одно ядро, прерывания обрабатываются по-старинке через PIC, а не APIC. Надо отметить, что народ с неистовым энтузиазмом копипастит этот совет по форумам.

* * *

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

3 декабря, 2012 - 15:30 — _passer

Цитата:
OProfile - 60% vmlinux

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

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

7 декабря, 2012 - 15:01 — Crontab

boroda, у меня та-же проблема!
Читал ваш пост, как будто я сам его писал. Давече в инете потратил несколько дней на огугливание проблемы и результат - 0. Могу сказать вам точно, что ядро 3.2.34 у меня таких проблем не вызвало, а всё что выше просто беда с подвисаниями. Сетевушка внешняя INTEL EXPI9301CT с чипом 82574L. И фикс с EEPROM я наложил, и с настройками BIOS игрался, результат отрицательный. Проблема появляется при определённых условиях: мелкие пакеты UDP и больше 16 IP юзеров. При этом гигабайты фильмов передаёт без запинки! Карта стоит в 100 Мбит/с фулл дуплекс через свитч. А вот тут я нагуглил то, что эти карты могут не дружить с дешёвыми свичами. Может в этом проблема? Потерял неделю на поиски решения, уже пожалел что взял именно эту карту, но на старом ядре 3.2.34 она работает идеально, значит проблема софтовая. И почему весь инет молчит? Разве мало серверов на чипах 82574L или мы особенные? Однозначно не пожалею денег и куплю гигабитный свитч Cisco, а потом отпишу.
Кстати, сетевой контроллер Realtek® 8111E даже с новейшими драйверами r8168 от производителя выделывает то-же самое на новых ядрах в той-же системе. Это снимает подозрения с глючности именно Intel'овских чипов.
Что то есть ядрёное в новых ядрах, но почему везде тишина?

Спасибо вам за содержательную тему! Я уже подумал, что я один столкнулся с подобным.

12 декабря, 2012 - 21:01 — Crontab

Проблема решена с помощью форума http://unixforum.org/index.php?showtopic=133681.
Особая и личная благодарность тов. Bizdelnick!

Мне было подсказано использовать патч для исправления багов: https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commitdiff;h=f5e37c549d200e3b899b66d6a84e99c8e2cf5e59

После этого я скомпилировал последний драйвер Intel e1000e 2.1.4 с указанными выше исправлениями и поставил на ранее проблемное ядро linux-3.6.9.
После перезагрузки, сеть на Intel 82574L заработала без проблем! Уже два часа работает как вкопанная, ни одного прерывания!

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

18 декабря, 2012 - 17:14 — _passer

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

—

Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!

Russian Gentoo Linux Community © 2005—2026
Gentoo — торговая марка Gentoo Foundation, Inc.
Сервер работает под управлением Gentoo Linux
Сайт работает под управлением CMS Drupal