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

Узкое место в шейпере на linux NASах

Если кратко - после набора ~700 ppppoe сессий и 450-500мбит трафика сервера доступа начинают 'тупить' - однопоточная закачка не разгоняется выше нескольких мбит(у пользователя нет ограничений вообще, должно быть 100мбит).

Linux 2.6.31, core 2 quad Q9550, сетевка на 82576(ET dual port). Сервер терминирует pppoe и шейпит с HTB(хеш-таблицы, u32), раньше использовался IMQ для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB, стало пролезать немного больше трафика, но полностью проблема не исчезла.

Сетевки привязаны к ядрам, загрузка не превышает 50%, потерь пакетов нет, и скорости нет. Стоит отключить шейпер - начинает пролезать трафика сколько в интерфейсы влезет, т.е. проблема в самом шейпере.

Где может быть узкое место? Устранять проблемы собирая очередной БРАС как-то не интересно.

Share this post


Link to post
Share on other sites
для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB

Т.е. шейпера вешаются не на ppp? А какая цель заворота через IFB?

Share this post


Link to post
Share on other sites
для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB

Т.е. шейпера вешаются не на ppp? А какая цель заворота через IFB?

Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов. В принципе избавиться от лишних прослоек было бы и не плохо.

Share this post


Link to post
Share on other sites

Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов.

И каким образом IFB это позволяет решить-то? :) У меня исход на IFB, вход на PPP - все прекрасно шейпится, с переменной скоростью. Даже рулится по CoA. Хеш-шейпер на 3к адресов (на каждый адрес по 3 класса!) на IFB, с недавнего времени - еще и дополнительно на 2 вланах (один - на мир, второй - UA-IX) для организации раздельной скорости некоторым пользователям. Никаких проблем не замечено. Нагрузка на каждый брас - порядка 300-400 сессий и 300+ мбит траффика.

 

Кстати, какова загрузка проца при этом?

Share this post


Link to post
Share on other sites

Я вешаю на ppp+ простой HTB внешка/свои_сети с парой фильтров. Описанной проблемы нет.

Edited by disappointed

Share this post


Link to post
Share on other sites

У меня тоже на PPP интерфейсах. TBF+PRIO (по сути тот же HTB). Тоже делю на классы (интернет/локалка). По 1200 сессий. CoA. accel-pppd. Проблем нет.

Edited by Ivan Rostovikov

Share this post


Link to post
Share on other sites

Цель - динамическое изменение скоростей в зависимости от времени суток/скачанного объема/загрузки каналов.

И каким образом IFB это позволяет решить-то? :) У меня исход на IFB, вход на PPP - все прекрасно шейпится, с переменной скоростью. Даже рулится по CoA. Хеш-шейпер на 3к адресов (на каждый адрес по 3 класса!) на IFB, с недавнего времени - еще и дополнительно на 2 вланах (один - на мир, второй - UA-IX) для организации раздельной скорости некоторым пользователям. Никаких проблем не замечено. Нагрузка на каждый брас - порядка 300-400 сессий и 300+ мбит траффика.

 

Кстати, какова загрузка проца при этом?

Биллинг по крону генерирует готовую болванку управления шейпером(файл с набором tc qdisc/tc filter для всех клиентов), на НАСах файл запускается и обновляет лимиты скорости, для такого подхода проще шейпить на стационарных интерфейсах. Плюс у клиентов может быть несколько ip адресов, все они шейпятся сообща, плюс лимиты строятся гибко в зависимости от текущей загрузки канала(ceil всегда тарифный, rate в зависимости от свободной полосы).

500 сессий машины обслуживают легко, а вот после ~600 начинаются тормоза. Загрузка процессора по ядрам пиково 0/0/30/40, если affitiny поставить для пары ядер - по 15% на ядро, ресурсов CPU полно. Или буфера где-то нужно увеличить, или настройки самого шейпера крутить..

Share this post


Link to post
Share on other sites

Есть ли смысл поднять на интерфейсе смотрящем в мир 2 очереди, а интерфейсов на которые поднимаются клиентские pppoe сессии сделать два?

И есть ли смысл пытаться переделать все на accel-ppp с его шейпером?

Share this post


Link to post
Share on other sites

Я бы для начала ядро обновил, до 2.6.35.14 к примеру (более свежие - были грабли с туннелями/шейперами, как в 3.0 - не знаю).

Share this post


Link to post
Share on other sites

Ядро обновить не так просто, биллинг для подсчета трафика используется патчи ipt_acct которых я под новые ядра не встречал..

Share this post


Link to post
Share on other sites

NiTr0

Вот так спасибо, я от них обновления ждал с 2009ого и думал что проект давно заброшен. Буду обновлять софт, а там посмотрим.

 

Проблема кстати проясняется, тормоза скорее не от большого числа сессий, а от банального перегруза по трафику(точнее по pps). Пока трафика меньше полугига, все ок даже при 800 сессий. Если 500+ мбит - тормозит. Осталось понять почему оно тормозит при 50% загрузке..

Share this post


Link to post
Share on other sites

Какое ядро лучше ставить для NAS'a терминирующего pppoe и шейпящего трафик? Как-то лениво проверять все версии подряд.

Share this post


Link to post
Share on other sites

Какое ядро лучше ставить для NAS'a терминирующего pppoe и шейпящего трафик? Как-то лениво проверять все версии подряд.

 

Наверное какие-либо из так называемых lts ядер. Напрмиер, в archlinux это 2.6.32.46, но я видел и 2.6.34.х вроде бы. Сейчас kernel.org не работает по известным причинам, так что решайте сами.

 

Вообще попробуйте 3.0.4 и, если с ним не будет глюков, то юзайте его. Если будут - смотрите на lts. Тут просто в соседней теме написано про страЩные глюки с igb.

Share this post


Link to post
Share on other sites

Скорее всего дело не совсем только в ядре. Тоже пытаюсь сделать общую полосу по ifb на HTB. После поиска стабильных ядер и igb дошел до 3.rc(3-4) брал и гита davem в августе. Так вот про бараны - упорно повторяется ситуация с общим htb и когда юзеров более 700 начинает зажимать полосу. Доводил до 2100 юзеров, ситуация еще хуже становится. Игрался размерами очередей, задирал общую полосу шейпера под 5 гигабит, увеличивал берсты - толку мало. Единственно что еще не проверил это тики (по умолчанию HZ=250) ну и вариант создания своего ifb на каждую группу по 700-800 юзерей. Да и конечно забыл уточнить, тарифы - мегабиты 5-55, безлимиты... Запас процев есть, сетевые - интел igb.

Share this post


Link to post
Share on other sites

Собрал пока новый мускулистый NAS на i5-2500@3.6Ггц, 630 сессий и 450/200мбит трафика полет отличный, загрузка 3-4%. По идее в час пик отберет под 1к сессий и метров 700 трафика, поглядим на его здоровье.

Edited by kayot

Share this post


Link to post
Share on other sites

upd: 800 сессий, 500-600мбит трафика. Загрузка 5-6%, тормозов нет и в помине(99мбит/с спидтест говорит).

Значит сама операция копирования трафика с eth/ppp интерфейса на виртуальные imq/ifb кривая и ресурсоемкая, более мощное железо сместило планку тормозов подальше.

Надо перестраивать все на шейпинг на юзерских ppp'шках, осталось придумать как в онлайне менять скорость для сессии. Может подскажете простое решение?

Share this post


Link to post
Share on other sites

Тыкните где почитать если не сложно, наш биллинг и с радиусом то работает с помощью костылей, все придется прикручивать ручками.

Share this post


Link to post
Share on other sites
осталось придумать как в онлайне менять скорость для сессии. Может подскажете простое решение?

У меня простым перебором ppp+ делается, грохается старый шейпер и заново конфигурится новый.

 

Но я это не использовал, написал для себя и отложил как недоделку, т.к. последовательный реконфигур занимает некоторое время, а за него может кто-то отключится / подключится и кому-то неверно встанет шейпер. По идее нужно ещё сразу перед моментом удаления структур tc делать проверку тот ли это ppp* который получен в результате запроса в БД в начале скрипта.

Share this post


Link to post
Share on other sites

Тыкните где почитать если не сложно, наш биллинг и с радиусом то работает с помощью костылей, все придется прикручивать ручками.

RFC3576

Его реализация для pppd - radcoad (тута постил тему), живет на моих брасах собссно с год без приключений. Хоть и выглядит коряво ввиду отсутствия времени и острой необходимости чистки кода.

Share this post


Link to post
Share on other sites

Использую с классами и хэш-фильтрами htb на ifb-интерфейсах (по два на каждом роутере в зависимости от dscp-бита, допустим, 0x80 на ifb0, а 0x84 на ifb1) промежуточных роутеров, на которые асимметрично исходящему роутится с помощью bgp_local_pref входящий трафик на абонентские /32 с бордера. Примерно 16000 фильтров и классов, трафик до 300-400 Mbps (FD), роутера два, на каждом из них loadavg и использование памяти практически нулевые (второе достигнуто отключением conntrack с -j NOTRACK в таблице raw). Ядро стоковое дебиановское, 2.6.32-5. При отключении одного из роутеров нагрузка не меняется, второй роутер просто для redundancy.

 

Обновляется это из Cron раз в сутки скриптом на Python, использующим XMLRPC-интерфейс самописной вещи, постепенно заменяющей UTM5, сначала строятся классы для каждого ifb, потом строятся с помощью найденной где-то в Интернете программки на C фильтры с использованием хэш-таблиц, а потом всё это обновляется с tc -b.

 

PPPoE и других туннелей на сети практически нет, так что немножко не в тему :)

Edited by GFORGX

Share this post


Link to post
Share on other sites

Трафика мало и интерфейсов 4 вместо тыщи, не тот случай.

Для себя решил - буду все-таки пилить accel-ppp и шейпинг на интерфейсах + COA. Надоели подобные неуловимые проблемы, хочу как у всех - тупит, значит или 100% загрузка CPU, или ошибки на интерфейсе :)

Share this post


Link to post
Share on other sites

Трафика мало и интерфейсов 4 вместо тыщи, не тот случай.

Это я всё к тому, что, на мой взгляд, неправильно шейпить прямо на BRAS на Линуксе.

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