Образовалась какая-то засада. Есть набор IP-адресов, достаточно большой, около 18000. Понятное дело, что надо бы использовать ipset, но руки не доходили. Раньше набор правил создавался за вменяемое время, включая ядро 4.1. Примерно 9 минут. С ядром 4.4 этот процесс длится 3 часа 5 минут.
А откат на предыдущее ядро ускоряет процесс? Это для того, что бы убедится что дело именно в ядре.
Да, с kernel-image-std-def-4.1.21-alt1 9 минут. Два раза перемерял и с ним, и с kernel-image-std-def-4.4.11-alt0.M80P.1. Сейчас ещё подумаю, где можно днём посмотреть и un-def 4.5 посмотрю.
И я ОС не обновлял. Это предварительный этап, p7 с ядром от p8. Как раз хотел убедиться, что всё хоршо, и обновиться до конца.
С ядром kernel-image-un-def-4.5.5-alt0.M80P.1 так же, как и с kernel-image-std-def-4.4.11-alt0.M80P.1, то есть, долго. Всё воспроизводится и после полного обновления до p8.
testcase нужен, можно пример какой-то скрипта простого, который можно запускать на любой конфигурации ?
как-то так (немного неаккуратно в плане -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, к примеру) уже создаётся изначально медленно. В принципе, тысяче на пяти правил уже заметно.
Created attachment 6738 [details] Нагенерированный файлик с IP-адресами
Посмотрю. А если тоже-самое попробовать с IPSET ? Там же тест тривиальный.
(In reply to comment #8) > А если тоже-самое попробовать с IPSET ? Там же тест тривиальный. Дошли руки. На 28000 ip-адресах сет заполняется одинаково примерно, за 62-64 секунды (и с 4.1.21-std-def, и с 4.4.30-std-def). В общем-то, оно решение, и правильное идеологически, но что сломали в iptables - непонятно. Может, что-то связанное с переходом на nftables ?
Вешайте это в апстрим, думаю что у нас здесь не решить такую ошибку. Апстрим, правда, скорее всего посоветует использовать ipset, там есть инструменты оптимизированные для загрузки большого количества адресов (опция restore).
https://bugzilla.kernel.org/show_bug.cgi?id=188251
Сергей, было бы неплохо в ту багу добавить скрипты для тестирования.
в рамках нашего проекта эта задача неисправима, да и ядро уже 6.6 и iptables уже устарел.
