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

[kayot]

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

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

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

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

[disappointed]

для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB

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

[kayot]

для заворота трафика с ppp-интерфейсов, сегодня наконец-то от него избавился заменив на IFB

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

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

[NiTr0]

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

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

 

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

[disappointed]

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

Edited September 13, 2011 by disappointed

[Ivan Rostovikov]

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

Edited September 13, 2011 by Ivan Rostovikov

[kayot]

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

И каким образом 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 полно. Или буфера где-то нужно увеличить, или настройки самого шейпера крутить..

[kayot]

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

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

[NiTr0]

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

[kayot]

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

[NiTr0]

http://www.intra2net.com/en/developer/ipt_ACCOUNT/index.php - вплоть до 2.6.37

[kayot]

NiTr0

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

 

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

[kayot]

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

[wtyd]

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

 

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

 

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

[Ivan Rostovikov]

Стоковое ядро из дебиана прекрасно "лопатит" трафик. И стабильно как камень.

[cpulink]

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

[kayot]

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

Edited September 14, 2011 by kayot

[kayot]

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

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

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

[Ivan Rostovikov]

Как раз для этого придумали CoA.

[kayot]

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

[disappointed]

осталось придумать как в онлайне менять скорость для сессии. Может подскажете простое решение?

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

 

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

[NiTr0]

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

RFC3576

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

[GFORGX]

Использую с классами и хэш-фильтрами 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 September 16, 2011 by GFORGX

[kayot]

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

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

[GFORGX]

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

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