Быстродействие u32

[Ivan Rostovikov]

Использую iptables для маркировки пакетов и последующей фильтрации.

Потом фильтр аля:

tc filter add dev $UP_IF parent 1: protocol ip prio 3 handle $UP_MARK fw classid 1:$UP_CLASSID

 

Вроде все устраивает, но последний анализ показал, что iptables слишком сильно грузит цп.

Чтоб отказаться от iptables планирую использовать фильтр "u32 match ip".

 

Будет быстрее чем метить iptables-ом ?

 

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

- тип и частоту - процессора.

- % загрузки.

- кол-во адресов онлайн.

- кол-во фильтров.

- скорость на интерфейсе.

 

[BETEPAH]

что-то никто не отозвался по теме

 

2Ivan Rostovikov: сам ещё не пробовал потестить? у меня такая же схема и тоже задумываюсь о снижении нагрузки, каждый процент сейчас важен. но от iptables всё равно не отказаться, кто-то должен же выпускать юзеров в инет.

Edited March 9, 2009 by BETEPAH

[Ivan Rostovikov]

У меня распределенная схема. Отключения абонентов реализованы непосредственно на NAS-ах. Чтоб отрубать и локалку.

C помощью ipset.

А на бридже - только шейпинг.

 

Я пока не пробовал. Жду можт кто отпишется. Судя по яндексу - u32 еще медленее чем iptables -t mange :-(

Попробую - отпишусь.

 

[sirmax]

Пробегала информация что маркирование - вообще медленная операция (у меня траффик на НАСах до 150 мбит, потому нагрузка копеечная)

[DemYaN]

что-то никто не отозвался по теме

 

2Ivan Rostovikov: сам ещё не пробовал потестить? у меня такая же схема и тоже задумываюсь о снижении нагрузки, каждый процент сейчас важен. но от iptables всё равно не отказаться, кто-то должен же выпускать юзеров в инет.

В принципе, для отключения/включения юзеров можно использовать tc filter ... action drop, однако будет ли такая схема быстрее - большой вопрос.

[Ivan Rostovikov]

Быстрее ipset ничего нету :-)

[Max P]

для того чтобы tc u32 быстро работал говорят нужно делать примерно так - http://lartc.org/howto/lartc.adv-filter.hashing.html

[BETEPAH]

для того чтобы tc u32 быстро работал говорят нужно делать примерно так - http://lartc.org/howto/lartc.adv-filter.hashing.html

если я правильно понял (с аглицким не очень дружу), то с помощью хеша просто делается ветвление, для снижения количества проверяемых правил, т.е. аналогично заворачиванию проверки iptables по разным цепочкам. и это сильно снизит нагрузку?

[Nic]

Ну в учетом того, что схема с MARK не поддается хешированию в части описания фильтров, существует такое кол-во пользователей (=кол-ву фильтров), при котором u32 будет быстрее при любом заданном соотношении скоростей этих операций...

В общем, по сути все упирается в вопрос: какая длина цепочки с MARK в iptables и кол-во фильтров?

если я правильно понял (с аглицким не очень дружу), то с помощью хеша просто делается ветвление, для снижения количества проверяемых правил, т.е. аналогично заворачиванию проверки iptables по разным цепочкам. и это сильно снизит нагрузку?

Очевидно сильно, при правильном использовании.

Просмотр 1 правила занимает n тактов ЦП.

Пусть в простой цепочке N правил. Тогда время ЦП для 1 пакета =n*N/2 (в среднем)

Поделим цепочку на k равных подцепочек. Получим время ЦП на пакет = n*N/k/2 (время для просмотра N/k цепочек) + n*N/k/2 (время для просмотра N/k правил в выбранной цепочке) = n*N/k.

Имеем выигрыш в k/2 раз. Для k=10 это в 5 раз, для k=100 это в 50 раз.

Можно конструировать многоуровневые хеши. Оправдано для большого N. Пример - организация страничного доступа к памяти ЭВМ. На существующих машинах бывает до 5 уровней вложения. На х86 - 3 уровня.

Edited March 10, 2009 by Nic

[SokolovS]

Скажу по опыту, u32 + хэширование при большом количестве tc фильтров на порядок быстрее. Хеширование использую как в примере LARTC по последнему байту IP адреса, планирую еще сделать по первому или первым двум, чтобы разные подсети тоже разделить.

 

Сравнивать даже смысла нет, линейный список фильтров по маркировке это ох...е, количество сопоставлений для каждого пакета + еще iptables маркировать должен. При u32 + хэширование - количество сопоставлений величина малая и постоянная, при правильной организации хеша. Хешировать кстати можно не только по IP, а вобще по любому байту пакета.

 

Можно вдумчиво прочитать предыдущий пост Nic и сделать те же самые выводы :)

[Ivan Rostovikov]

Убедили... :-)

 

Киньте ссылкой на русскоязычный аналог http://lartc.org/howto/lartc.adv-filter.hashing.html ?

 

[BETEPAH]

спасибо за инфу, главное, что уяснил, что tc тоже надо ветвить, не знал что он так умеет и что тоже большую нагрузку даёт

 

2 Ivan Rostovikov:

http://www.opennet.ru/docs/RUS/LARTC/x1661.html

 

 

[Ivan Rostovikov]

Вах !

Спасибо !

[BETEPAH]

после двух дней экспериментов отвечу по теме:

у меня были правила на 1500 юзеров на каждый интерфейс, 2 интерфейса, MARK c форвардом ветвился, а tc конечно нет.

теперь остались теже правила на 1 интерфейсе, ветвистый форвард, вместо MARK теперь u32 match, входящий теперь шейплю через ингресс, там тоже соответственно u32. т.е. правил стало меньше, а нагрузка на сервер возросла. итог: маркировка с ветвлением жрёт меньше ресурсов, чем u32, для u32 обязательно вводить хеширование, т.е. ветвление.

[SokolovS]

Вывод! Неправильно приготовил! Такого не может быть в природе.

 

Так а расскажите что за ingress такой? Я видимо отстал от нововведений tc. Что уже и входящий на одном интерфейсе шейпить можно?

[BETEPAH]

делается всё очень легко, сначала вешаем дисциплину:

$tc qdisc add dev eth0 handle ffff: ingress

ну а потом фильтры на юзеров:

$tc filter add dev eth0 parent ffff: protocol ip pref ${2} u32 match ip src ${3} police rate ${5}kbit burst ${burst}k drop flowid :1

где $2 - id юзера, $3 - его ip, $5 - его скорость на аплоад

а самое главное, про что ни в одной доке не сказано и из-за этого я убил целый день на выяснение, что если в tc используем u32, а не марк, то обязательно указывать различный pref, у меня привязывается к id юзера, иначе у всех правил будет одинаковый pref и при удалении одного, будут удаляться все, либо надо вычислять в скрипте, какой handle у правила и удалять через него.

 

точность правда невысокая, но мне это и не требуется и путём экспериментов выяснил, что надо burst вычислять, должно быть примерно 1/100 к rate

 

ну а насчёт нагрузки, вот график:

 

[micros]

делается всё очень легко...

ну а насчёт нагрузки, вот график....

Красота. Кстати - это отличный пример когда шейпер и НАТ на одной машине с 2мя интерфейсами.

to ВЕТЕРАН, а чем график отрисован если не секрет?

п.с. как еще можно шейпить на одной машине вместе с NAT не прибегая к IMQ?

 

[DemYaN]

... входящий теперь шейплю через ингресс, там тоже соответственно u32. т.е. правил стало меньше, а нагрузка на сервер возросла. итог: маркировка с ветвлением жрёт меньше ресурсов, чем u32, для u32 обязательно вводить хеширование, т.е. ветвление.

только это у же не шейп, а полисинг

[SokolovS]

2ВЕТЕРАН:

Ты проверял количество проходов по фильтрам? Генери поток пакетов с какого нибудь IP и смотри как увеличиваются счетчики, через tc -s filter ls dev <dev>. По идее счетчики при трафике только с данного IP должны увеличиваться на фильтре который отвечает за выбор хеш-таблицы и у фильтров внутри хеш-таблицы.

 

Покажи пример входящего шейпа, на 1-м юзере.

 

К примеру мои данные:

Сервер на Intel Core Quad 6600, сетевушки e1000, работает в режиме моста, только шейпит и фильтрует.

Кол-во правил: 1500 на каждый интерфейс.

Трафик: в пике 120 Мбит

Загрузка: в пике 6-7%. (в основном система).

Edited March 15, 2009 by SokolovS

[BETEPAH]

Кстати - это отличный пример когда шейпер и НАТ на одной машине с 2мя интерфейсами.

а кто сказал, что здесь и натится? у меня для этого отдельный серв с микротиком.

 

а чем график отрисован если не секрет?

http://munin.projects.linpro.no/

 

только это у же не шейп, а полисинг

ну да, неправильно выразился, конечно полисинг, тоже меньше нагрузка чем шейп

 

Ты проверял количество проходов по фильтрам? Генери поток пакетов с какого нибудь IP и смотри как увеличиваются счетчики

я ещё не использую хеширование, раздумываю над алгоритмом, я два дня убил только на введение u32.

насчёт примера не понял, вроде в предыдущем посте всё расписал подробно

Edited March 15, 2009 by BETEPAH

[Ivan Rostovikov]

>либо надо вычислять в скрипте, какой handle у правила и удалять через него.

 

Как можете предложить вычислять "handle" ?

[SokolovS]

А зачем в фильтре rate указывается? Для ingress что-ли? При переходе с плоского fw mark на плоский u32, разницы практически не будет. Сделаешь хэширование, заметишь большую разницу. Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674

Edited March 15, 2009 by SokolovS

[SokolovS]

>либо надо вычислять в скрипте, какой handle у правила и удалять через него.

 

Как можете предложить вычислять "handle" ?

Я думаю что del конкретных правил особо не нужен, для изменения правила можно replace делать. А вот в раз в сутки перезагружать шейпер полностью, удалением корневых дисциплин (черевато потерей связи на неск. секунд тут писал). Ведь тарифы не меняют чаще чем раз в сутки.

[BETEPAH]

ты не понял, если как в доках у всех правил prio 5, то удаляются все и не важно, что тарифы раз в сутки меняются, может кто-то из клиентов любит выключать свой инет через личный кабинет при выключении компа, тогда настаёт трындец абсолютно всем правилам. чтобы реплейс сделать, тоже надо хэндл вычислить, иначе как указать какое правило заменить? либо как у меня счас через разный prio.

 

Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674

у меня так и было, просто начал проводить эксперименты на этой неделе, ищу наилучшую конфигурацию. сегодня утром вернул обратно на оба интерфейса, но через u32, т.е. отказался от ингресс. нагрузка ничуть не изменилась. тут не сказывается, htb это или простой полисер, жрёт процессор исключительно u32. буду хеширование делать. вот только думаю, не скажется ли то, что у всех правил разный prio указываю, т.е. насколько я понял это порядок просмотра правил, а они в разные таблицы будут вставляться?

[BETEPAH]

Как можете предложить вычислять "handle" ?

как вариант по юзер_ид:

[root@billing ~]# tc filter show dev eth0 | grep 5001
filter parent 1: protocol ip pref 5001 u32
filter parent 1: protocol ip pref 5001 u32 fh d10: ht divisor 1
filter parent 1: protocol ip pref 5001 u32 fh d10::800 order 2048 key ht d10 bkt 0 flowid 1:5001