LINUX.ORG.RU
ФорумAdmin

Высокая загрузка CPU от ksoftirqd kworker


0

1

Имеем небольшой домашний шлюз на AMD E-350, ubuntu server 12.04. Собственно в последние дни заметил сие.

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    3 root      20   0     0    0    0 R   71  0.0  14:02.70 ksoftirqd/0
 9229 root      20   0     0    0    0 R   19  0.0   2:09.26 kworker/0:0

В htop одно из ядер почти на 90 загружено softirq, другое на половину. Происходит при скачивании из интернета. Вне зависимости, качает сам шлюз или это транзитный трафик. Скорость при уэтом упирается в 20мбит (по тарифу чуть больше).

Ядро свое, с imq и ndpi. Но они непричем, так как ядро почти год использую, а подобное началось пару дней как.

Еще немного информации

 cat /proc/interrupts
           CPU0       CPU1
  0:         36          0    XT-PIC-XT-PIC    timer
  1:          3          0    XT-PIC-XT-PIC    i8042
  2:          0          0    XT-PIC-XT-PIC    cascade
  7:          1          0    XT-PIC-XT-PIC
  8:          1          0    XT-PIC-XT-PIC    rtc0
  9:          0          0    XT-PIC-XT-PIC    acpi
 11:     632948          0    XT-PIC-XT-PIC    ahci, ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7
 12:          5          0    XT-PIC-XT-PIC    i8042
 14:          0          0    XT-PIC-XT-PIC    pata_atiixp
 15:          0          0    XT-PIC-XT-PIC    pata_atiixp
 16:    2823315        456   PCI-MSI-edge      eth0
 17:   19289775        179   PCI-MSI-edge      eth1
 18:          0          2   PCI-MSI-edge      radeon
NMI:        786        603   Non-maskable interrupts
LOC:   14373929    2629348   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:        743        560   Performance monitoring interrupts
IWI:          0          0   IRQ work interrupts
RTR:          0          0   APIC ICR read retries
RES:     614603    2987932   Rescheduling interrupts
CAL:        400        618   Function call interrupts
TLB:      22353      18444   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:         42         42   Machine check polls
ERR:          1
MIS:          0
Обработку прерываний на другое ядро перекидывал. Но это только повлияло на то, что теперь другое ядро полностью загружено, второе на половину.
lspci | grep  Ethernet
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)

в syslog и dmesg ничего подозрительного. Тип соединения pptp (использую accel-ppp)

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

★★

Ответ на: комментарий от blind_oracle

Естественно я отключал шейпер

Правила


iptables-save
# Generated by iptables-save v1.4.12 on Sat May 24 23:09:24 2014
*nat
:PREROUTING ACCEPT [11:721]
:INPUT ACCEPT [10:626]
:OUTPUT ACCEPT [20:1292]
:POSTROUTING ACCEPT [20:1292]
-A PREROUTING -s 192.168.1.15/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -s 192.168.1.16/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3128
-A PREROUTING -p tcp -m tcp --dport 5522 -j DNAT --to-destination 192.168.1.2:5522
-A PREROUTING -p udp -m udp --dport 5533 -j DNAT --to-destination 192.168.1.2:5533
-A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE
COMMIT
# Completed on Sat May 24 23:09:25 2014
# Generated by iptables-save v1.4.12 on Sat May 24 23:09:25 2014
*mangle
:PREROUTING ACCEPT [355:51393]
:INPUT ACCEPT [341:40599]
:FORWARD ACCEPT [14:10794]
:OUTPUT ACCEPT [337:52250]
:POSTROUTING ACCEPT [351:63044]
COMMIT
# Completed on Sat May 24 23:09:25 2014
# Generated by iptables-save v1.4.12 on Sat May 24 23:09:25 2014
*filter
:INPUT DROP [1:95]
:FORWARD ACCEPT [5:486]
:OUTPUT ACCEPT [345:53322]
:UPNP - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m udp --dport 33459 -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 21,30000:30100 -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --sport 53 -m state --state NEW -j ACCEPT
-A INPUT -i ppp0 -p udp -m udp --dport 9800:9812 -j ACCEPT
-A INPUT -i ppp0 -p tcp -m tcp --dport 9800:9812 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -s 192.168.1.0/24 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Sat May 24 23:09:25 2014

as_lan ★★
() автор топика

ndpi

ksoftirqd

ndpi что-то обрабатывает? Обработка сетевого трафика происходит в этих ksoftirqd

Везде речь о прерываниях, но это итак понятно.

Речь о softirq, это не настоящие обработчики прерываний.

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

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

as_lan ★★
() автор топика
Ответ на: комментарий от i-rinat

Давно бы сделал, но ядро свое, а под него не получается поставить linux-tools, даже если указываю поставить ту же версию, из которой собрал ядро.Ругается на разность версий.

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

не получается поставить linux-tools

А просто скачать пакет и вытащить из него бинарник не судьба? На крайний случай можно собрать perf из исходников.

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

даа... Странно, до этого я таблицу очищал, нагрузка особо не спадала. Сейчас же почти на 80% процентов упала.

Таблицы большие. Вот тут я писал зачем мне это ip rule flush не удаляет все (комментарий)

Думал если их загнать через ip rule в отдельную таблицу так будет лучше. Теперь надо будет попробовать как и советовали через ipset

as_lan ★★
() автор топика
Ответ на: комментарий от i-rinat

Ну а что делать?) Отлавливать каждый ip адрес и в ручную добавлять?)

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

Теперь надо будет попробовать как и советовали через ipset

Фигню посоветовали. 100500 маршрутов в таблице это нормально, и я не утрирую. Вон всякие железки типа microtic или vyatta в крейсерском режиме по 350к роутов перемалывают (full-view ага)

Отсюда вывод что таблица маршрутизации в линупс вполне приспособлена к большому количеству записей.

По опыту могу сказать что сильно тормозит если много правил в цепочках iptables, и по опыту же могу сказать что обычно там 90% правил не нужно. То же самое касается большого количества правил ip rules (2-3 лишних правила это не большое количество)

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

В iptables правил мало. выше уже написал какие. А вот наличие маршрутов в таблице дает сильную нагрузку.

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

E-350 - очень не быстрый процессор.

Если ты используешь большое число правил маршрутизации ( ip rule flush не удаляет все ), то это сильно нагружает процессор. Переделай на вариант с ipset и большая часть проблем уйдет.

pptp c компрессией тоже должно жрать и без того дохлый процессор.

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

А вот наличие маршрутов в таблице дает сильную нагрузку.

Если свести количество маршрутов с 1500 до 15 то проблем нет?

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

Так стоп. Где именно у тебя сейчас 100500 записей? ip rules? ip route?

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

pptp c компрессией тоже должно жрать и без того дохлый процессор.

Компрессию выключил.

Если свести количество маршрутов с 1500 до 15 то проблем нет?

Нет. Чем больше правил, тем больше нагрузка.

Так стоп. Где именно у тебя сейчас 100500 записей? ip rules? ip route?

ip rule. в ip route есть таблица. а через ip rule в эту таблицу 1500 правил.

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

ip rule. в ip route есть таблица. а через ip rule в эту таблицу 1500 правил.

Так понятное дело, цепочка ip rule обрабатывается последовательно, там никаких хешей никаких деревьев. Совсем другое дело таблица ip route. (Обратите внимание на разницу между цепочка и таблица)

Я бы добавлял все записи в таблицу маршрутизации и не парился. Тормозить оно не будет, инфа 142%. Можно сделать через ipset. Через ipset тормозить тоже не будет. Ну понятное дело что в разумных пределах (300 мегабит и 80к пакетов оно осилит точно)

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

Просто в таблицу маршрутизации не хотелось. Вдруг надо найти свои локальные маршруты какие то, а приходиться среди этих 1500 искать.

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

Всё это можно сделать просто голыми руками: одно правило в ip rules и одну дополнительную табличку маршрутизации mytable например:

ip route add 3.4.5.6 via altgw table mytable # all 100500 routes here 
ip route add 3.4.5.7 via altgw table mytable # all 100500 routes here
ip route add 3.4.5.8 via altgw table mytable # all 100500 routes here
ip rule add from all lookup mytable

Само собой нужно добавить таблицу в /etc/iproute2/rt_tables, убедиться что правило с lookup mytable стоит перед остальными правилами, и что в таблице mytable нет никакого default

Тогда destination которые есть в таблице mytable будут уходить в altgw, а которых нету — будут продолжать маршрутизироваться дальше по цепочке, т.е. как обычно

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

ТО есть если у меня только 5% трафика надо отправлять через другой маршрут, а 95% через дефолт, то все эти 95% все время будут проверяться по этой цепочке?

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

Будет поиск в таблице, да. Но точно так же нужен поиск в таблице ipset в случае с ipset. И это еще вопрос что хуже, потому что у ip route есть кеш, а у ipset — нет

redixin ★★★★
()
30 декабря 2014 г.
Ответ на: комментарий от as_lan

Малость апну тему. На текущий момент количество адресов в таблице увеличилось до 3546 =) С ipset нагрузка как и раньше практически нулевая. Конечно в этом списке 99,98% адресов мусор. Но хотя бы задумываться о блокировках не приходиться. Как я понял список на актуальность не проверяют, а тупо добавляют новые адреса.

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

костыли к рашке нагнули линупс, ахах

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