fcm1

Ну что никто не выложит решение? Такая же проблема на CentOS 6.5 x86_64 сейчас.

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

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

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

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

Спасибо почитал, покурил... Глянул в свои фильтры. Всё ещё не понимаю откуда проблема. Структура такая: Хеш-таблицы: 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 как и говорил. Буду копать дальше, я так понимаю я перехожу в разряд читателей до завтра.

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

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