Перейти к содержимому
Калькуляторы

Узкое место в шейпере на 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%, потерь пакетов нет, и скорости нет. Стоит отключить шейпер - начинает пролезать трафика сколько в интерфейсы влезет, т.е. проблема в самом шейпере.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем disappointed

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем Ivan Rostovikov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

NiTr0

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

RFC3576

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем GFORGX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.