Jump to content
Калькуляторы

Быстродействие u32 шейпинг iproute tc u32

Использую 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-ом ?

 

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

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

- % загрузки.

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

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

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

 

Share this post


Link to post
Share on other sites

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

 

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

Edited by BETEPAH

Share this post


Link to post
Share on other sites

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

C помощью ipset.

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

 

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

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

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
что-то никто не отозвался по теме

 

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Ну в учетом того, что схема с 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 by Nic

Share this post


Link to post
Share on other sites

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

$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

 

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

 

billing_cpu_week.png

Share this post


Link to post
Share on other sites
делается всё очень легко...

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

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

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

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

 

Share this post


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

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

Share this post


Link to post
Share on other sites

2ВЕТЕРАН:

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

 

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

 

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

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

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

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

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

Edited by SokolovS

Share this post


Link to post
Share on other sites
Кстати - это отличный пример когда шейпер и НАТ на одной машине с 2мя интерфейсами.
а кто сказал, что здесь и натится? у меня для этого отдельный серв с микротиком.

 

а чем график отрисован если не секрет?
http://munin.projects.linpro.no/

 

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

 

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

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

Edited by BETEPAH

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Edited by SokolovS

Share this post


Link to post
Share on other sites
>либо надо вычислять в скрипте, какой handle у правила и удалять через него.

 

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

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

Share this post


Link to post
Share on other sites

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

 

Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674
у меня так и было, просто начал проводить эксперименты на этой неделе, ищу наилучшую конфигурацию. сегодня утром вернул обратно на оба интерфейса, но через u32, т.е. отказался от ингресс. нагрузка ничуть не изменилась. тут не сказывается, htb это или простой полисер, жрёт процессор исключительно u32. буду хеширование делать. вот только думаю, не скажется ли то, что у всех правил разный prio указываю, т.е. насколько я понял это порядок просмотра правил, а они в разные таблицы будут вставляться?

Share this post


Link to post
Share on other sites
Как можете предложить вычислять "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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this