e1000e периодические подвисания
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
Если кто-то сталкивался с этой проблемой, подскажите, как ее решить?
Судя по форумам с проблема не очень популярна, конкретных решений или объяснений найти не удалось.
- Для комментирования войдите или зарегистрируйтесь
Проверьте ваш ли это
Проверьте ваш ли это случай:
http://sourceforge.net/projects/e1000/files/e1000e%20stable/eeprom_fix_82574_or_82583/
Кроме того можно попробовать использовать не ядренный модуль, а какой-то из этих:
http://sourceforge.net/projects/e1000/files/e1000e%20stable/
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
Возможно, что случай мой
EEPROM на моей карте требовал фикса. Проверил под тестом на 40Мбит/с и 7000pps - проблема не проявилась, la поднялся только до 0,20. Посмотрим, что будет завтра под рабочей нагрузкой.
Огромное спасибо!
EEPROM не помог
Жаль, но дело не в EEPROM или не только в нем. Ночью попробую поставить новую версию драйвера. Удивительно, что искуственная нагрузка не вызвала проблему, которая проявилась при более низкой рабочей нагрузке. Разница в размерах пакетов и в том, что в рабочем варианте они приходят с разных IP на разные порты. В обоих случаях - это 99% UDP пакеты.
Есть еще один сервер со старым ядром и аналогичной сетевой картой - работает с такой же нагрузкой и практически ее не замечает. Будет возможность сравнивать настройки.
Нашел интересную информацию: http://rajven.ru/articles/optimizacija_nastroek_drajverov_dlja_kart_intel/index.html. Вдруг, кому-то будет полезно.
У меня такие карты лопатят по
У меня такие карты лопатят по 500-700М, в пиках до 800М. Очереди прибиты к ядрам процессора, подобран размер кольцевого буфера и работает себе. Проблем нет.
Относительно ссылки по I/OAT DMA - давно включено, и т.к. конфиг ядра давно уже определен, то об этом я уже успел забыть.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
Не надо обобщать
Верю. Имеется еще четыре сервера, которые прекрасно работают с такими же сетевыми картами под не меньшей нагрузкой, и этот прекрасно работал до обновления ядра.
Прошлой ночью пробовал обновить драйвер e1000e до 2.1.4. Не помогло. Решил откатиться до последнего ядра ветки 3.0 - 3.0.35. Проблема стала немного другой - сеть работает без потери пакетов, но la может подпрыгивать до 3.00 без изменений в нагрузке и потом сразу опускаться до 0.50.
Следующей ночью попробую вернуться на прежнее собранное ядро, когда система летала и нагрузка не ощущалась.
Кстати, на других серверах все IRQ, включая от сетевой карты, распределяются по всем ядрам процессора, а на этом сервере они отрабатываются только каким-то одним ядром. При этом smp_affinity разрешает использовать все ядра. Если указать конкретное ядро, то оно выбирается, если указать несколько ядер, то все равно используется одно из разрешенных. Я не помню, как это работало на старом ядре, но что-то мне кажется, что это тоже играет свою роль в проблеме.
С помощью smp_affinity таки
С помощью smp_affinity таки стоит прибить очереди к ядрам конкретным. Определенно не лишнее и полезное.
Покажите вывод профайлера и top'а. Уж больно интересно что там у вас творится.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
при таких нагрузках - это
при таких нагрузках - это бесполезное занятие. Я бы поигрался с ethtool, потом бы собрал модулем свежий драйвер, потом бы поменял сетевухи.
Штиль на 3.0.6
Ночью откатился до ранее собранного ядра 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: 0Core 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Ваши мысли не особо
Ваши мысли не особо подтверждаются практикой: имею на хозяйстве кучу Xeon X3440, E5420, E5507, E3-1220 и правда, только один i5. На всех ксеонах по-умолчанию прерывания от устройств размазываются по всем ядрам.
P.S. oprofile - установите и проследите, что у вас создает такую нагрузку.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
oprofile попробую
Что тогда может мешать прерываниям размазываться по ядрам? На второй машине с Core i3 работает ядро с точь-в-точь таким же конфигом и прерывания размазываются. Это как бы факультативный вопрос, ибо на старом ядре сервер прекрасно работает, хотя прерывания не размазываются.
С oprofile разберусь, что к чему.
Флудить не буду, как разберусь или появятся вопросы - отпишусь.
Результаты
Результаты не впечатляют. Перечитал много форумов и статей. Определенно успешного рецепта не нашел - кому-то, что-то помогает путем проб и ошибок. Мой путь привел к следующим выводам:
1. IRQ не распределяются по ядрам в соответствии с алгоритмом round-robin, так как это платформенно-зависимая "фича". И если материнская плата или BIOS не желают того делать в конкретной комплектации, то хоть тресни - оно не заработает. Вместо этого и придуман smp_affinity, чтобы хоть как-то распределить нагрузку по ядрам. В этом плане хорошо описано в книге "Understanding the Linux Kernel" на стр. 159 "IRQ distribution in multiprocessor systems":
Кроме того это подтверждается практикой братьев по несчастью. На форумах описывались случаи, когда из 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. Запланирую переход на другое железо, потом продолжу тесты с этим сервером, чтобы не вредить качеству услуг.
Цитата: OProfile - 60%
Как бы наводит на размышления что не факт что это драйвер ядра так шалит.
Во-вторых, при вашей нагрузке настройкой сетевух можно вообще не заморачиваться. А сравнить конфиг ядра разных версий.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!
Вид сбоку
boroda, у меня та-же проблема!
Читал ваш пост, как будто я сам его писал. Давече в инете потратил несколько дней на огугливание проблемы и результат - 0. Могу сказать вам точно, что ядро 3.2.34 у меня таких проблем не вызвало, а всё что выше просто беда с подвисаниями. Сетевушка внешняя INTEL EXPI9301CT с чипом 82574L. И фикс с EEPROM я наложил, и с настройками BIOS игрался, результат отрицательный. Проблема появляется при определённых условиях: мелкие пакеты UDP и больше 16 IP юзеров. При этом гигабайты фильмов передаёт без запинки! Карта стоит в 100 Мбит/с фулл дуплекс через свитч. А вот тут я нагуглил то, что эти карты могут не дружить с дешёвыми свичами. Может в этом проблема? Потерял неделю на поиски решения, уже пожалел что взял именно эту карту, но на старом ядре 3.2.34 она работает идеально, значит проблема софтовая. И почему весь инет молчит? Разве мало серверов на чипах 82574L или мы особенные? Однозначно не пожалею денег и куплю гигабитный свитч Cisco, а потом отпишу.
Кстати, сетевой контроллер Realtek® 8111E даже с новейшими драйверами r8168 от производителя выделывает то-же самое на новых ядрах в той-же системе. Это снимает подозрения с глючности именно Intel'овских чипов.
Что то есть ядрёное в новых ядрах, но почему везде тишина?
Спасибо вам за содержательную тему! Я уже подумал, что я один столкнулся с подобным.
Решено!
Проблема решена с помощью форума 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. Уверен, что мои проблемы больше не повторятся и канут в небытие после фикса в новых ядрах...
Я бы сказал мыльницы,
Извиняюсь за оффтоп, но я бы сказал, что мыльницы, особенно подгоревшие, не дружат с чем Ктулху угодно.
Нащяльника, мая сервира паставиль, фрибизьдя инсталя сделаль, апачи сабраль, пыхапе патключиль, сапускаю, а ано - ажамбех пашамбе эшельбе шайтанама!