LINUX.ORG.RU
ФорумAdmin

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


0

0

Имеется роутер
uname -a
Linux unlim 2.6.30.8 #4 SMP Mon Nov 23 15:12:05 SAMT 2009 i686 Intel(R) Xeon(R) CPU E5506
@ 2.13GHz GenuineIntel GNU/Linux

К нему по ВПН подключаются клиенты до 260-300 штук.
Периодически, а точнее раз в несколько дней,(как правило при максимуме подключенных клиентах)
происходит вот что:
top
top - 19:48:12 up 2 days, 1:01, 246 users, load average: 1.58, 1.50, 1.35
Tasks: 587 total, 2 running, 585 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 100.0% id, 0.0% wa, 0.0% hi, 0.0% si
Cpu2 : 0.0% us, 4.5% sy, 0.0% ni, 54.5% id, 0.0% wa, 0.0% hi, 40.9% si
Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 2.2% hi, 97.8% si
Mem: 3104160k total, 882172k used, 2221988k free, 120556k buffers
Swap: 11727432k total, 0k used, 11727432k free, 516696k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

10 root 15 -5 0 0 0 R 100 0.0 7:04.42 ksoftirqd/3

как видно 4-ое ядро загружено на 100%. Соответсвенно падает производительность.
На этом ядре висит прерывание от сетевой карты eth0 - той самой, куда коннектяться клиенты. Если перебросить с помощью smp_affinity прерывание от этой сетевухи на другое ядро - будет тоже самое с ним.

сетевухи встроенные гигабитные Intel. Мать Asus серверная.
Драйвера скачал с сайта intel
modinfo /lib/modules/2.6.30.8/kernel/drivers/net/e1000e/e1000e.ko
filename: /lib/modules/2.6.30.8/kernel/drivers/net/e1000e/e1000e.ko
version: 1.0.15-NAPI
license: GPL
description: Intel(R) PRO/1000 Network Driver

Загрузка сетевухи около 10 килопакетов в сек.
Что интересно постоянно растёт количество drop пакетов. Может быть это как-то связано ?
ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:26:18:66:1B:66
inet addr:******** Bcast:*********** Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1166452253 errors:2 dropped:60573 overruns:0 frame:2
TX packets:1258741423 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:336512668 (320.9 Mb) TX bytes:150763710 (143.7 Mb)

Помогает от этого только перезагрузка. После этого пара дней всё в порядке. Есть у кого-нибудь мысли?

покажите

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

ventilator ★★★ ()

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

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

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, тут я уже рыл, он работает на ура.

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

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

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

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

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

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

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

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

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

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

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

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

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 ★★★★★ ()
Ответ на: комментарий от injektor

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

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

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

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)

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

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

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)

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

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

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.

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

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

файрволле


+1

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

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

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

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

ventilator ★★★ ()

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

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

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


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

AS ★★★★★ ()
Ответ на: комментарий от AS
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 вас явно дезинформировали - даже сраный реалтек тянет больше.

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