Bug 32157 - с ядром 4.4 крайне медленно стали создаваться правила iptables
Summary: с ядром 4.4 крайне медленно стали создаваться правила iptables
Status: NEW
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-std-def (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: Vitaly Chikunov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-31 02:00 MSK by Sergey Y. Afonin
Modified: 2016-11-21 17:17 MSK (History)
3 users (show)

See Also:


Attachments
Нагенерированный файлик с IP-адресами (184.34 KB, application/gzip)
2016-05-31 17:22 MSK, Sergey Y. Afonin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2016-05-31 02:00:43 MSK
Образовалась какая-то засада. Есть набор IP-адресов, достаточно большой, около 18000. Понятное дело, что надо бы использовать ipset, но руки не доходили. Раньше набор правил создавался за вменяемое время, включая ядро 4.1. Примерно 9 минут. С ядром 4.4 этот процесс длится 3 часа 5 минут.
Comment 1 Anton Farygin 2016-05-31 07:33:16 MSK
А откат на предыдущее ядро ускоряет процесс?
Это для того, что бы убедится что дело именно в ядре.
Comment 2 Sergey Y. Afonin 2016-05-31 08:25:49 MSK
Да, с kernel-image-std-def-4.1.21-alt1 9 минут. Два раза перемерял и с ним, и с kernel-image-std-def-4.4.11-alt0.M80P.1. Сейчас ещё подумаю, где можно днём посмотреть и un-def 4.5 посмотрю.
Comment 3 Sergey Y. Afonin 2016-05-31 08:28:09 MSK
И я ОС не обновлял. Это предварительный этап, p7 с ядром от p8. Как раз хотел убедиться, что всё хоршо, и обновиться до конца.
Comment 4 Sergey Y. Afonin 2016-05-31 15:05:59 MSK
С ядром kernel-image-un-def-4.5.5-alt0.M80P.1 так же, как и с kernel-image-std-def-4.4.11-alt0.M80P.1, то есть, долго. Всё воспроизводится и после полного обновления до p8.
Comment 5 Anton Farygin 2016-05-31 15:12:14 MSK
testcase нужен, можно пример какой-то скрипта простого, который можно запускать на любой конфигурации ?
Comment 6 Sergey Y. Afonin 2016-05-31 17:21:06 MSK
как-то так (немного неаккуратно в плане -N/-F, но сойдёт для теста):

========
iptables -t nat -N TEST_CHAIN
iptables -t nat -F TEST_CHAIN

IP_LIST=/tmp/iplist.txt

for IP in `cat $IP_LIST`; do
        echo iptables -t nat -A TEST_CHAIN -d $IP -j DNAT --to 127.0.0.2
        iptables -t nat -A TEST_CHAIN -d $IP -j DNAT --to 127.0.0.2
done
========

Начинается всё быстро, но замедляется в процессе. При этом, если одна здоровенная цепочка создана, то вторая (TEST_CHAIN2, к примеру) уже создаётся изначально медленно. В принципе, тысяче на пяти правил уже заметно.
Comment 7 Sergey Y. Afonin 2016-05-31 17:22:08 MSK
Created attachment 6738 [details]
Нагенерированный файлик с IP-адресами
Comment 8 Anton Farygin 2016-05-31 21:08:39 MSK
Посмотрю.

А если тоже-самое попробовать с IPSET ? Там же тест тривиальный.
Comment 9 Sergey Y. Afonin 2016-11-09 12:13:42 MSK
(In reply to comment #8)

> А если тоже-самое попробовать с IPSET ? Там же тест тривиальный.

Дошли руки. На 28000 ip-адресах сет заполняется одинаково примерно, за 62-64 секунды (и с 4.1.21-std-def, и с 4.4.30-std-def). В общем-то, оно решение, и правильное идеологически, но что сломали в iptables - непонятно. Может, что-то связанное с переходом на nftables ?
Comment 10 Anton Farygin 2016-11-09 15:39:27 MSK
Вешайте это в апстрим, думаю что у нас здесь не решить такую ошибку.
Апстрим, правда, скорее всего посоветует использовать ipset, там есть инструменты оптимизированные для загрузки большого количества адресов (опция restore).
Comment 11 Sergey Y. Afonin 2016-11-21 17:10:51 MSK
https://bugzilla.kernel.org/show_bug.cgi?id=188251
Comment 12 Anton Farygin 2016-11-21 17:17:30 MSK
Сергей, было бы неплохо в ту багу добавить скрипты для тестирования.