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

Linux tc, ограничение на количество фильтров

На удивление этот вопрос достаточно плохо гуглится, знаю что здесь есть спецы, которые возможно помогут пролить свет на проблему.

 

Система CentOS 6.5 x86_64. Ядро из коробки: Linux version 2.6.32-431.3.1.el6.x86_64

 

Делаю шейпер на основе HTB. Нужно ограничение на общий канал для всех, ограничение для каждого ip + приоретизация по траффику для каждого ip. Решено, что динамическое шейпирование HTB которое оценивает загрузку канала parent и в зависимости от этого увеличивает или ужимает канал для юзера, подходит как нельзя кстати. IP-шников планируется 3+ тысячи. В общем, получается довольно много классов, фильтров и всего прочего. При добавлении примерно после 2тыс. фильтров начинает сыпать ошибку RTNETLINKS answers: File exists. Понятно что где-то ограничение на кол-о правил, в ядре скорее всего. Вопрос такого плана: увеличить макс. значение при помощи sysctl, /proc и т.д. реально, если да то где? Или же значение жёстко зашито в ядро и всё гораздо сложнее? Нужны советы, в общем. Спасибо.

Share this post


Link to post
Share on other sites

Нет там никаких ограничений, где-то у вас в скриптах ошибки.

08:45:51 root#nas3 ~ #service shaper status | grep filter | wc -l
12658
08:46:28 root#nas3 ~ #uname -a
Linux nas3.xxx 2.6.31.9-174.1.bill.x86_64 #1 SMP Tue Dec 29 23:01:51 EET 2009 x86_64 x86_64 x86_64 GNU/Linux

Никакого тюнинга, древнее ядро.

Share this post


Link to post
Share on other sites

Ошибка появляется при добавлении правил, раскидывающих хосты по u32 таблицам. Почему я сделал вывод о том что есть ограничение на количество правил? Вот пример фильтров:

 

tc filter add dev eth0 protocol ip parent 2: u32 ht 902:1: match ip src 172.16.17.1 flowid 2:1
......
tc filter add dev eth0 protocol ip parent 2: u32 ht 909:dc: match ip src 172.16.24.220 flowid 2:2012

 

И таких правил много. Суть в том что если вначале убрать N правил, то ошибка появляется ровно на N правил позже. Например если убрать 5 правил вначале то, ошибка будет не на flowid 2:2012, а на flowid 2:2017. Я уже не знаю, куда копать.

Share this post


Link to post
Share on other sites

Я бы сказал, где-то хеши неправильно строятся. И получаются 'одинаковые' фильтры, вот оно и ругается на exist.

Как вариант - попробуйте без хешей залить весь список для теста.

Share this post


Link to post
Share on other sites

В u32 есть некоторые ограничения, связанные со структурой хеш-таблиц, а именно на идентификацию всех сущностей классификатора u32:

1. На идентфикацию хеш-таблицы выделено 12 бит - это первые три шестнадцатеричных числа в хендле фильтра.

2. На идентификацию столбцов (они же ячейки, они же buckets) выделено только 8 бит - это два шестнадцатеричных числа в середине хендла.

3. На идентификацию элемента фильтра внутри ячейки так же 12 бит - последние три шестнадцатеричных числа.

 

На первый взгляд кажется, что вы не учли ограничение на количество столбцов в хеш-таблице.

 

Ссылки для чтения - раз и два

Edited by evil-man

Share this post


Link to post
Share on other sites

На первый взгляд кажется, что вы не учли ограничение на количество столбцов в хеш-таблице

 

Спасибо почитал, покурил... Глянул в свои фильтры. Всё ещё не понимаю откуда проблема. Структура такая:

Хеш-таблицы: 902-912, для подсеток, везде divisor 256.

В таблицах хост добавляется по последнему октету, т.е. по идее нигде ничего не превышено.

 

Все хендлы для моих фильтров можно описать псевдокодом:

for table in 902..912 do
 for i in 00 to FF do
   $table:$i:800
 done
done

 

Структура сети такая что есть хосты и с октетом 0 и с 255, так что я везде делаю от 0 до 255 включительно.

Соответственно псевдокоду ошибка начинается при добавлении правила с хендлом 909:DC:800, но я вроде нигде не вылезаю за пределы значений хендлов. У всех таблиц divisor 256 как и говорил.

 

Буду копать дальше, я так понимаю я перехожу в разряд читателей до завтра.

Share this post


Link to post
Share on other sites

Кто вообще видел цыфры производительности. Какие вообще реальные цифры данного шейпера? в тысячах пользователей?

Edited by nshut

Share this post


Link to post
Share on other sites

Кто вообще видел цыфры производительности. Какие вообще реальные цифры данного шейпера? в тысячах пользователей?

U32 - это классификатор, а не шейпер. Можно его хоть под завязку набить. А это 2^32 фильров u32, но часть из них уйдёт для ссылок, поэтому на самом деле чуть поменьше.

Share this post


Link to post
Share on other sites
классификатор, а не шейпер

это я понимаю. Меня конкретно интересует практическое использование.

т.е. те кто использует может назовет цифры: 2Гб/с - 2к пользователей, цпу загрузка столько то процентов.

Share this post


Link to post
Share on other sites

Немного докопался до сути. Для правил, раскидывающих хосты по таблицам я не указывал хендлы. То есть, по умолчанию для правил типа tc filter хендлы создавались автоматически с номерами 800. Вот такого вида: $table:$bucket:800. Ну и при достижении определённого количества таких правил новые просто не добавляются, с чем это связано я не знаю. Тогда я начал указывать хендлы, например для таблицы 1 $table:$bucket:1, для таблицы 2 $table:$bucket:2 и т.д. Ну вроде бы поборол, теперь все правила добавляются. Но теперь вылезла другая проблема, шейпер не справляется с нагрузкой.

 

Железо:

8 x Xeon® CPU E31240 3.3Ghz

RAM: 4G

Сетевуха: Intel 82576 Gbit Ethernet, создаёт отдельные очереди прерываний на каждое ядро.

 

Система CentOS 6.5, обновлена. Ядро Linux version 2.6.32-431.1.2.0.1.el6.x86_64. Снимаются 2 влана с одного интерфейса, итого имеем eth0.10 (local), на нём шейпим download и eth0.20 (inet), здесь шейпим upload, но уже по другой пачке адресов, т.к. на сервере ещё работает NAT через iptables (решено было обойтись без проброса трафика на ifb0 и шейпинга upload на нём). Далее говорим только про шейпинг download. Корневой класс htb rate 480mbit, далее 3 тыс. дочерних классов адресов конкретных хостов (rate 8mbit ceil 25 mbit) и столько же правил, раскидывающих хосты по u32 таблицам (12 таблиц). То есть всё как бы должно работать быстро. Но по факту получаем следующее: до применения правил шейпера ~500mbit/s трафика; ок применяем шейпер - пропускает только около 250mbit через себя (а должен 480 минимум), тест скорости на конкретном хосте через шейпер показывает макс. 3mbit/s на загрузку. При проверке по tc -s -d show, - всё работает, хосты попадают в наши дочерние вёдра htb. 50-100 тыс. PPS. Дропов на интерфейсах нет. Процы загружены все на 50-70% по top (soft interrupts). Пинги на шлюз (шейпер) ходят без потерь. Вот не могу понять, это реально машина не справляется, или же где-то в настройках собака порылась.

 

Что я пробовал для решения проблемы:

- увеличивал txqueuelen на интерфейсах

- игрался со значениями r2q, quantum для классов htb

- Убирал шейпинг c inet интерфейса, оставлял только на локальном (download)

- оставлял машину без шейпинга, только nat и маршрутизация; всё работает идеально, 500mbit в лёгкую, загрузка процов 5-10%;

что говорит нам о проблемах именно в шейпере

 

Ничего из этого не помогает, шейпер упорно не выдаёт больше 3mbit/хост, 250mbit/общий канал при вышеуказанных настройках. Что можете посоветовать?

Share this post


Link to post
Share on other sites

Выключите оффлоады на сетевых.

ethtool -K eth0 gso off gro off tso off lro off

ethtool -K eth1 gso off gro off tso off lro off

 

У меня сервер в конфигурации:

4x ядерный Xeon X3220 @ 2,4ГГц и 4Гб памяти, сетевуха Intel 82576 натит и шейпит 700мбит на вход и 200мбит на выход в ЧНН

Загрузка процессора колеблется вблизи 50%, правда стоит тротлинг перываний

options igb QueuePairs=0,0 RSS=2,2 InterruptThrottleRate=8000,8000

 

Шейпится на eth1 исходящий к клиентам трафик и на ifb входящий от них.

Всего чуть более 1800 классов.

Share this post


Link to post
Share on other sites

Не помогает выключение оффлоадов. При выключении gro ещё хуже, общий трафик падает.

Share this post


Link to post
Share on other sites

Поставил параметры модуля: options igb QueuePairs=0,0 RSS=8,8 InterruptThrottleRate=8000,8000

 

Не помогает.

Share this post


Link to post
Share on other sites

RSS=8,8

Зря. У вас 4-х ядерный процессор, т.е. по 2 очереди на сетевую надо сделать и закрепить за ядрами. Впрочем на такой загрузке это не критично. Где-то вы накосячили или с шейпером или файерволом.

Share this post


Link to post
Share on other sites

И не могли помочь никакие шаманства с опциями драйвера или оффлоадами. Вероятно у вас хеширование не работает, проверяйте счетчики правил.

Share this post


Link to post
Share on other sites

htb rate 480mbit, далее 3 тыс. дочерних классов адресов конкретных хостов (rate 8mbit ceil 25 mbit)

Это не относится (наверное) к проблеме загрузки CPU, но вы нарушили правило: Сумма rate всех дочерних классов не должна быть больше rate родительского класса. Т.е. 480Mbit/3000 классов = rate клиентского класса (в вашем случае) может быть 160Kbit максимум!!! Лучше поставить 100, для запаса, или поднимать rate родительского класса. Иначе пользовательское ограничение не будет работать.

Ceil оставляйте какой есть.

Share this post


Link to post
Share on other sites

Убрал всю тучу фильтров, поставил пока просто, общее ведро на 480, и 2 дочерних - важный/неважный трафик. Как часы! Загрузка процов 1.5%. Значит скорее всего где-то в скрипте косяк. Но пока так и не понял где именно, хотя уже сто раз мануал по U32 раскурил.

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