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

1. Правила файрволла в студию

2. Отключить всякие шейперы типа этого imq и т.п.

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

Правила

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

ndpi

ksoftirqd

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

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

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

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

# perf top -U

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

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

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

первые 2 строки 32,07% [kernel] [k] fib4_rule_match 30,27% [kernel] [k] fib_rules_lookup

Что-то он у тебя усердно маршрутизирует. Таблицы маршрутизации большие?

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

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

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

Пятнадцать сотен маршрутов. А ты суров.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё это можно сделать просто голыми руками: одно правило в 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, а которых нету — будут продолжать маршрутизироваться дальше по цепочке, т.е. как обычно

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

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

Спасибо Вам добрый человек. Действительно пока увеличения нагрузки нет.

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

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