fcm1 Опубликовано 30 января, 2014 · Жалоба На удивление этот вопрос достаточно плохо гуглится, знаю что здесь есть спецы, которые возможно помогут пролить свет на проблему. Система 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 и т.д. реально, если да то где? Или же значение жёстко зашито в ядро и всё гораздо сложнее? Нужны советы, в общем. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 января, 2014 · Жалоба Нет там никаких ограничений, где-то у вас в скриптах ошибки. 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 Никакого тюнинга, древнее ядро. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 30 января, 2014 · Жалоба Ошибка появляется при добавлении правил, раскидывающих хосты по 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. Я уже не знаю, куда копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 января, 2014 · Жалоба Я бы сказал, где-то хеши неправильно строятся. И получаются 'одинаковые' фильтры, вот оно и ругается на exist. Как вариант - попробуйте без хешей залить весь список для теста. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evil-man Опубликовано 30 января, 2014 (изменено) · Жалоба В u32 есть некоторые ограничения, связанные со структурой хеш-таблиц, а именно на идентификацию всех сущностей классификатора u32: 1. На идентфикацию хеш-таблицы выделено 12 бит - это первые три шестнадцатеричных числа в хендле фильтра. 2. На идентификацию столбцов (они же ячейки, они же buckets) выделено только 8 бит - это два шестнадцатеричных числа в середине хендла. 3. На идентификацию элемента фильтра внутри ячейки так же 12 бит - последние три шестнадцатеричных числа. На первый взгляд кажется, что вы не учли ограничение на количество столбцов в хеш-таблице. Ссылки для чтения - раз и два Изменено 30 января, 2014 пользователем evil-man Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 30 января, 2014 · Жалоба На первый взгляд кажется, что вы не учли ограничение на количество столбцов в хеш-таблице Спасибо почитал, покурил... Глянул в свои фильтры. Всё ещё не понимаю откуда проблема. Структура такая: Хеш-таблицы: 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 как и говорил. Буду копать дальше, я так понимаю я перехожу в разряд читателей до завтра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 30 января, 2014 (изменено) · Жалоба Кто вообще видел цыфры производительности. Какие вообще реальные цифры данного шейпера? в тысячах пользователей? Изменено 30 января, 2014 пользователем nshut Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
evil-man Опубликовано 30 января, 2014 · Жалоба Кто вообще видел цыфры производительности. Какие вообще реальные цифры данного шейпера? в тысячах пользователей? U32 - это классификатор, а не шейпер. Можно его хоть под завязку набить. А это 2^32 фильров u32, но часть из них уйдёт для ссылок, поэтому на самом деле чуть поменьше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nshut Опубликовано 30 января, 2014 · Жалоба классификатор, а не шейпер это я понимаю. Меня конкретно интересует практическое использование. т.е. те кто использует может назовет цифры: 2Гб/с - 2к пользователей, цпу загрузка столько то процентов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 12 февраля, 2014 · Жалоба Немного докопался до сути. Для правил, раскидывающих хосты по таблицам я не указывал хендлы. То есть, по умолчанию для правил типа 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/общий канал при вышеуказанных настройках. Что можете посоветовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
gibbon Опубликовано 12 февраля, 2014 · Жалоба Выключите оффлоады на сетевых. 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 классов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 12 февраля, 2014 · Жалоба Не помогает выключение оффлоадов. При выключении gro ещё хуже, общий трафик падает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 12 февраля, 2014 · Жалоба Поставил параметры модуля: options igb QueuePairs=0,0 RSS=8,8 InterruptThrottleRate=8000,8000 Не помогает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 12 февраля, 2014 · Жалоба RSS=8,8 Зря. У вас 4-х ядерный процессор, т.е. по 2 очереди на сетевую надо сделать и закрепить за ядрами. Впрочем на такой загрузке это не критично. Где-то вы накосячили или с шейпером или файерволом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 12 февраля, 2014 · Жалоба И не могли помочь никакие шаманства с опциями драйвера или оффлоадами. Вероятно у вас хеширование не работает, проверяйте счетчики правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Susanin Опубликовано 13 февраля, 2014 · Жалоба htb rate 480mbit, далее 3 тыс. дочерних классов адресов конкретных хостов (rate 8mbit ceil 25 mbit) Это не относится (наверное) к проблеме загрузки CPU, но вы нарушили правило: Сумма rate всех дочерних классов не должна быть больше rate родительского класса. Т.е. 480Mbit/3000 классов = rate клиентского класса (в вашем случае) может быть 160Kbit максимум!!! Лучше поставить 100, для запаса, или поднимать rate родительского класса. Иначе пользовательское ограничение не будет работать. Ceil оставляйте какой есть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fcm1 Опубликовано 14 февраля, 2014 · Жалоба Убрал всю тучу фильтров, поставил пока просто, общее ведро на 480, и 2 дочерних - важный/неважный трафик. Как часы! Загрузка процов 1.5%. Значит скорее всего где-то в скрипте косяк. Но пока так и не понял где именно, хотя уже сто раз мануал по U32 раскурил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...