[fcm1]

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

 

Система 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 и т.д. реально, если да то где? Или же значение жёстко зашито в ядро и всё гораздо сложнее? Нужны советы, в общем. Спасибо.

[kayot]

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

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

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

[fcm1]

Ошибка появляется при добавлении правил, раскидывающих хосты по 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. Я уже не знаю, куда копать.

[kayot]

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

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

[evil-man]

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

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

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

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

 

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

 

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

Изменено 30 января, 2014 пользователем evil-man

[fcm1]

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

 

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

Хеш-таблицы: 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 как и говорил.

 

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

[nshut]

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

Изменено 30 января, 2014 пользователем nshut

[evil-man]

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

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

[nshut]

классификатор, а не шейпер

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

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

[fcm1]

Немного докопался до сути. Для правил, раскидывающих хосты по таблицам я не указывал хендлы. То есть, по умолчанию для правил типа 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/общий канал при вышеуказанных настройках. Что можете посоветовать?

[gibbon]

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

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 классов.

[fcm1]

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

[fcm1]

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

 

Не помогает.

[passer]

RSS=8,8

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

[kayot]

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

[Susanin]

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

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

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

[fcm1]

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