LINUX.ORG.RU

softirqd жрет 100% CPU


0

0

Есть сервер, роутящий локалку на 1000 человек, такой конфы:
2х Xeon 2.6hHz, 1GB RAM, стоит гигабитная оптическая сетевуха (acenic), подняты VLAN'ы. Для обсчета трафика стоит ipcad.

Периодически ksoftirqd на первом проце начинает кушать 100%, пинги поднимаются до 50-100мс, народ ругается. Так же во время такого безобразия ipcad начинает жрать 30-50% проца.

Походу какой-то очередной сетевой срач, но при чем тут ksoftirqd? Сетевуха вроде бы не должна кушать проц. В iptables порядка 2000 правил.

$ lspci
00:00.0 Host bridge: Intel Corporation E7505 Memory Controller Hub (rev 03)
00:00.1 Class ff00: Intel Corporation E7505/E7205 Series RAS Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation E7505/E7205 PCI-to-AGP Bridge (rev 03)
00:02.0 PCI bridge: Intel Corporation E7505 Hub Interface B PCI-to-PCI Bridge (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 02)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 02)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)
02:1c.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
02:1d.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04)
02:1e.0 PIC: Intel Corporation 82870P2 P64H2 I/OxAPIC (rev 04)
02:1f.0 PCI bridge: Intel Corporation 82870P2 P64H2 Hub PCI Bridge (rev 04)
03:01.0 Ethernet controller: Alteon Networks Inc. AceNIC Gigabit Ethernet (rev 01) <-- та самая сетевуха
03:03.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
04:03.0 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10)
04:03.1 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10)
05:01.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
05:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)

Дистрибутив: Fedora Core 4
Ядро: 2.6.15-1.1833_FC4smp

anonymous

Может всё же ядро обновить? Сейчас актуально 2.6.23.8

birdie ★★★★★
()

>Походу какой-то очередной сетевой срач, но при чем тут ksoftirqd? Сетевуха вроде бы не должна кушать проц. В iptables порядка 2000 правил.

ИМХО, все логично. Если я правильно помню, то пакет основное время обрабатывается как раз в режиме softirq, в режиме блокировки происходит только передача пакета из сетевки в буфер в оперативной памяти. Все остальное --- прохождение по iptables, маршрутизация происходит без блокировки. При этом, если при небольшом потоке сетевых пакетов сразу после обработки аппаратного прерывания вызывается обработчик softirq. А при большом потоке пакетов == много softirq уже начинает работать softirqd...

mky ★★★★★
()
Ответ на: комментарий от mky

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

anonymous
()
Ответ на: комментарий от anonymous

Я почти уверен это из-за ipcad, он тормозной libpcap наверняка используется? Гигабит это не шухры мухры, сложно его отроутить и обсчитать.

Xeonы какие? Не woodcrest, старые? Если так, попробуй заменить железо на core2quad и сетевуху intel на pci-express обязательно!

anonymous
()
Ответ на: комментарий от anonymous

Думаю, сначала надо внимательно изучить информацию о трафике в моменты "подвисания". Определить кол-во пакетов в секунду, размер этих пакетов, с каких ip-адресов идет поток и т.д.

Если это действительно сетевой флуд, то его лучше давить, чем пытаться отроутить. Насколько я знаю у провадеров автоматический скрипт (или человек :) ) переодически анализирует трафик и блокирует машины с "нездоровой" сетевой активностью. А обратно, бывает, только по просьбе клиента разблокирует.

mky ★★★★★
()
Ответ на: комментарий от anonymous

Используется libpcap, да. Еще он вроде бы умеет через ULOG, так будет лучше? А то я слышал что на ULOG при большой нагрузке оно теряет трафик.

Зеоны хз, наверно старые, PCI Express там нету, только PCI-X, где и торчит гигабитная сетевуха.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.