Перегрузка ядра CPU на роутере

> Драйвера скачал с сайта intel

а штатные не заработали?

смысле, те что в ведре были

покажите

sysctl net.netfilter.nf_conntrack_max
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_buckets
ethtool -S eth0

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

Десять килопакетов это не нагрузка, уж тем более для такого процессора.

Какой у вас впн, poptop?

isden: В ядре дрова почему-то без поддержки NAPI Но ставил и их, проблема сохраняется.

CyberTribe:

Смотрел. Обычные VPN пакеты.

Ventiliator: net.netfilter.nf_conntrack_max = 65536 net.netfilter.nf_conntrack_count = 26335 net.netfilter.nf_conntrack_buckets = 16384 ethtool -S eth0 там дофига всего выводит, нужно всё или что-то конкретно ? VPN accel_pptp, тут я уже рыл, он работает на ура.

rx_no_buffer_count

правила иптейблс/шейпинг/нат есть?

rx_no_buffer_count: 0
нат и шейпинг есть, кой-какие правила iptables тоже

а как шейпинг организован? Вы пробовали отключить шейпинг и очистить иптейблс?

шейпинг через tc Отключать и чистить не пробовал. Есои удалить правила, прервётся клиентский траффик и нагрузка пропадёт. Вы думаете в этом может быть дело ? Не в прерываниях сет. карты ? Почему тогда нагрузка отображается в виде процесса ksoftircd ? Проблема проявляется именно со временем. Сейчас аот например при той же нагрузке всё в порядке. А со временем возникает процесс ksoftircd или events и сжирает 100% ядра на котором висит сет. карта.

Что tc и так понятно. У вас хештаблицы или линейно правила для каждого клиента? Попробуйте выключить шейпинг и посмотреть как изменится нагрузка. Попробуйте убрать из iptables все что не касается ната и посмотреть как изменится ситуация. Опять же, не добавляется ли у вас на каждого клиента какое-то правило?

ksoftirqd - это не только прерывания, а еще и netfilter, tc и вообще все что с пакетом происходит

> isden: В ядре дрова почему-то без поддержки NAPI Но ставил и их, проблема сохраняется.

посмотри режим работы сетевухи, в некоторых переключение из PIO в DMA существенно снижало нагрузку на проц.

посмотри режим работы сетевухи, в некоторых переключение из PIO в DMA существенно снижало нагрузку на проц.

PIO/DMA это не из области винтов разве?

http://en.wikipedia.org/wiki/Programmed_input/output

Programmed input/output (PIO) is a method of transferring data between the CPU and a peripheral such as a network adapter or an ATA storage device.

In general, programmed I/O happens when software running on the CPU uses instructions that access I/O address space to perform data transfers to or from an I/O device. This is contrast to Direct Memory Access (DMA) transfers.

isden
Не подскажете как посмотреть режим ? Погуглил не нашёл.

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

нет, просто качал с сайта интел и компилил

а у модуля есть какие параметры ? ну т.е., например :

denis@laptop:/$ modinfo iwl3945 | grep parm
parm: antenna:select antenna (1=Main, 2=Aux, default 0 [both]) (int)
parm: swcrypto:using software crypto (default 1 [software])
parm: disable_hw_scan:disable hardware scanning (default 0) (int)
parm: fw_restart3945:restart firmware in case of error (int)

я не видел у интелового драйвера параметров связанных с дма

vermagic:       2.6.31-rc9ona preempt mod_unload modversions
parm:           copybreak:Maximum size of packet that is copied to a new buffer on receive (uint)
parm:           TxIntDelay:Transmit Interrupt Delay (array of int)
parm:           TxAbsIntDelay:Transmit Absolute Interrupt Delay (array of int)
parm:           RxIntDelay:Receive Interrupt Delay (array of int)
parm:           RxAbsIntDelay:Receive Absolute Interrupt Delay (array of int)
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (array of int)
parm:           SmartPowerDownEnable:Enable PHY smart power down (array of int)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (array of int)
parm:           CrcStripping:Enable CRC Stripping, disable if your BMC needs the CRC (array of int)

советую искать проблему в шейперах/файрволле

Ventiliator:
в шейперах маловероятно, так как шейпится исходящий с роутера траффик, а проблема возникает на ядре, которое управляет прерываниями eth0-rx.
Фаервол статический: там пара десятков правил всего, вряд ли тоже.
Сейчас вспомнил, что начало проблемы совпало с переходом с ядра 2.6.25 на 2.6.30.8. И я почитал , что в 2.6.30 как раз что-то намудрили с прерываниями.
В общем пока обновился на 2.6.32.10, на штатных дровах. Пока всё нормально.Загрузка сейчас 11-12 кпакетов, 4-ое ядро в среднем 95% idle.
Если будут проблемы, откачусь обратно на 2.6.25.

В общем отпишусь через несколько дней о результатах. Спасибо всем за участие.

файрволле

+1

обычно когда в файрволле много правил и они плохо оптимизированы, то такая проблема имеет место быть.

за версией ядра гонится только школота

Странно, вы спрашиваете совета, но попробовать предложенное не хотите.

PS: на роутерах неплохо держать свежее ядро, обычно с ростом версии производительность роутинга тоже повышается)

> сетевухи встроенные гигабитные Intel. Мать Asus серверная.

Только не факт, что сетевухи там серверные... И где-то оно близко к пределу, мне называли 12Kpps цифру на обычных интеловских.

Помогает от этого только перезагрузка.

После перезагрузки количество сессий восстанвливается до того же уровня, и всё работает ? Или, всё-таки, сессий меньше становится активных ? А если просто все сессии посбрасывать, что происходит ? Если не справляется именно сетевуха, по идее, должно без перезагрузки проходить... Если, действительно, только перезагрузка помогает, то это нехорошие какие-то последствия получаются...

bras-f0#ethstats | grep eth1
  eth1:  109.78 Mb/s In    46.13 Mb/s Out -  26837.0 p/s In   15518.0 p/s Out

ethtool -i eth1
driver: r8169
version: 2.3LK-NAPI
firmware-version:
bus-info: 0000:02:0c.0

Про 12kpps вас явно дезинформировали - даже сраный реалтек тянет больше.