Ivan Rostovikov Опубликовано 4 марта, 2009 · Жалоба Использую 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-ом ? У кого такая схема работает, прошу написать Ваши результаты по быстродействию. - тип и частоту - процессора. - % загрузки. - кол-во адресов онлайн. - кол-во фильтров. - скорость на интерфейсе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 9 марта, 2009 (изменено) · Жалоба что-то никто не отозвался по теме 2Ivan Rostovikov: сам ещё не пробовал потестить? у меня такая же схема и тоже задумываюсь о снижении нагрузки, каждый процент сейчас важен. но от iptables всё равно не отказаться, кто-то должен же выпускать юзеров в инет. Изменено 9 марта, 2009 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 9 марта, 2009 · Жалоба У меня распределенная схема. Отключения абонентов реализованы непосредственно на NAS-ах. Чтоб отрубать и локалку. C помощью ipset. А на бридже - только шейпинг. Я пока не пробовал. Жду можт кто отпишется. Судя по яндексу - u32 еще медленее чем iptables -t mange :-( Попробую - отпишусь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 9 марта, 2009 · Жалоба Пробегала информация что маркирование - вообще медленная операция (у меня траффик на НАСах до 150 мбит, потому нагрузка копеечная) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 9 марта, 2009 · Жалоба что-то никто не отозвался по теме 2Ivan Rostovikov: сам ещё не пробовал потестить? у меня такая же схема и тоже задумываюсь о снижении нагрузки, каждый процент сейчас важен. но от iptables всё равно не отказаться, кто-то должен же выпускать юзеров в инет. В принципе, для отключения/включения юзеров можно использовать tc filter ... action drop, однако будет ли такая схема быстрее - большой вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 10 марта, 2009 · Жалоба Быстрее ipset ничего нету :-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Max P Опубликовано 10 марта, 2009 · Жалоба для того чтобы tc u32 быстро работал говорят нужно делать примерно так - http://lartc.org/howto/lartc.adv-filter.hashing.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 10 марта, 2009 · Жалоба для того чтобы tc u32 быстро работал говорят нужно делать примерно так - http://lartc.org/howto/lartc.adv-filter.hashing.html если я правильно понял (с аглицким не очень дружу), то с помощью хеша просто делается ветвление, для снижения количества проверяемых правил, т.е. аналогично заворачиванию проверки iptables по разным цепочкам. и это сильно снизит нагрузку? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Nic Опубликовано 10 марта, 2009 (изменено) · Жалоба Ну в учетом того, что схема с 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 уровня. Изменено 10 марта, 2009 пользователем Nic Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 11 марта, 2009 · Жалоба Скажу по опыту, u32 + хэширование при большом количестве tc фильтров на порядок быстрее. Хеширование использую как в примере LARTC по последнему байту IP адреса, планирую еще сделать по первому или первым двум, чтобы разные подсети тоже разделить. Сравнивать даже смысла нет, линейный список фильтров по маркировке это ох...е, количество сопоставлений для каждого пакета + еще iptables маркировать должен. При u32 + хэширование - количество сопоставлений величина малая и постоянная, при правильной организации хеша. Хешировать кстати можно не только по IP, а вобще по любому байту пакета. Можно вдумчиво прочитать предыдущий пост Nic и сделать те же самые выводы :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 11 марта, 2009 · Жалоба Убедили... :-) Киньте ссылкой на русскоязычный аналог http://lartc.org/howto/lartc.adv-filter.hashing.html ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 11 марта, 2009 · Жалоба спасибо за инфу, главное, что уяснил, что tc тоже надо ветвить, не знал что он так умеет и что тоже большую нагрузку даёт 2 Ivan Rostovikov: http://www.opennet.ru/docs/RUS/LARTC/x1661.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 11 марта, 2009 · Жалоба Вах ! Спасибо ! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 13 марта, 2009 · Жалоба после двух дней экспериментов отвечу по теме: у меня были правила на 1500 юзеров на каждый интерфейс, 2 интерфейса, MARK c форвардом ветвился, а tc конечно нет. теперь остались теже правила на 1 интерфейсе, ветвистый форвард, вместо MARK теперь u32 match, входящий теперь шейплю через ингресс, там тоже соответственно u32. т.е. правил стало меньше, а нагрузка на сервер возросла. итог: маркировка с ветвлением жрёт меньше ресурсов, чем u32, для u32 обязательно вводить хеширование, т.е. ветвление. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 13 марта, 2009 · Жалоба Вывод! Неправильно приготовил! Такого не может быть в природе. Так а расскажите что за ingress такой? Я видимо отстал от нововведений tc. Что уже и входящий на одном интерфейсе шейпить можно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 14 марта, 2009 · Жалоба делается всё очень легко, сначала вешаем дисциплину: $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 ну а насчёт нагрузки, вот график: Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
micros Опубликовано 14 марта, 2009 · Жалоба делается всё очень легко...ну а насчёт нагрузки, вот график.... Красота. Кстати - это отличный пример когда шейпер и НАТ на одной машине с 2мя интерфейсами. to ВЕТЕРАН, а чем график отрисован если не секрет? п.с. как еще можно шейпить на одной машине вместе с NAT не прибегая к IMQ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DemYaN Опубликовано 14 марта, 2009 · Жалоба ... входящий теперь шейплю через ингресс, там тоже соответственно u32. т.е. правил стало меньше, а нагрузка на сервер возросла. итог: маркировка с ветвлением жрёт меньше ресурсов, чем u32, для u32 обязательно вводить хеширование, т.е. ветвление. только это у же не шейп, а полисинг Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 15 марта, 2009 (изменено) · Жалоба 2ВЕТЕРАН: Ты проверял количество проходов по фильтрам? Генери поток пакетов с какого нибудь IP и смотри как увеличиваются счетчики, через tc -s filter ls dev <dev>. По идее счетчики при трафике только с данного IP должны увеличиваться на фильтре который отвечает за выбор хеш-таблицы и у фильтров внутри хеш-таблицы. Покажи пример входящего шейпа, на 1-м юзере. К примеру мои данные: Сервер на Intel Core Quad 6600, сетевушки e1000, работает в режиме моста, только шейпит и фильтрует. Кол-во правил: 1500 на каждый интерфейс. Трафик: в пике 120 Мбит Загрузка: в пике 6-7%. (в основном система). Изменено 15 марта, 2009 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 15 марта, 2009 (изменено) · Жалоба Кстати - это отличный пример когда шейпер и НАТ на одной машине с 2мя интерфейсами.а кто сказал, что здесь и натится? у меня для этого отдельный серв с микротиком. а чем график отрисован если не секрет? http://munin.projects.linpro.no/ только это у же не шейп, а полисингну да, неправильно выразился, конечно полисинг, тоже меньше нагрузка чем шейп Ты проверял количество проходов по фильтрам? Генери поток пакетов с какого нибудь IP и смотри как увеличиваются счетчикия ещё не использую хеширование, раздумываю над алгоритмом, я два дня убил только на введение u32.насчёт примера не понял, вроде в предыдущем посте всё расписал подробно Изменено 15 марта, 2009 пользователем BETEPAH Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 15 марта, 2009 · Жалоба >либо надо вычислять в скрипте, какой handle у правила и удалять через него. Как можете предложить вычислять "handle" ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 15 марта, 2009 (изменено) · Жалоба А зачем в фильтре rate указывается? Для ingress что-ли? При переходе с плоского fw mark на плоский u32, разницы практически не будет. Сделаешь хэширование, заметишь большую разницу. Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674 Изменено 15 марта, 2009 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 15 марта, 2009 · Жалоба >либо надо вычислять в скрипте, какой handle у правила и удалять через него. Как можете предложить вычислять "handle" ? Я думаю что del конкретных правил особо не нужен, для изменения правила можно replace делать. А вот в раз в сутки перезагружать шейпер полностью, удалением корневых дисциплин (черевато потерей связи на неск. секунд тут писал). Ведь тарифы не меняют чаще чем раз в сутки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 15 марта, 2009 · Жалоба ты не понял, если как в доках у всех правил prio 5, то удаляются все и не важно, что тарифы раз в сутки меняются, может кто-то из клиентов любит выключать свой инет через личный кабинет при выключении компа, тогда настаёт трындец абсолютно всем правилам. чтобы реплейс сделать, тоже надо хэндл вычислить, иначе как указать какое правило заменить? либо как у меня счас через разный prio. Если НАТа нет, то я бы раскидал правила по интерфейсам так: http://forum.nag.ru/forum/index.php?showtopic=47674 у меня так и было, просто начал проводить эксперименты на этой неделе, ищу наилучшую конфигурацию. сегодня утром вернул обратно на оба интерфейса, но через u32, т.е. отказался от ингресс. нагрузка ничуть не изменилась. тут не сказывается, htb это или простой полисер, жрёт процессор исключительно u32. буду хеширование делать. вот только думаю, не скажется ли то, что у всех правил разный prio указываю, т.е. насколько я понял это порядок просмотра правил, а они в разные таблицы будут вставляться? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 15 марта, 2009 · Жалоба Как можете предложить вычислять "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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...