Настройка FreeBSD

[nightfly 1 241]

Количество пайпов создает некую статическую нагрузку но ею можно принебречь. При запихивании юзеров в них при помощи tablearg на количествах пайпов до 15-20к проблем вообще не должно возникать без какого либо тюнинга.

 

Основным потребителем ресурсов на таких задачах является проход по правилам ipfw сверху вниз. Выборки по tablearg на порядки быстрее чем линейный проход. При таком подходе попытки уменьшить еще и количество пайпов за счет шейпа по маске прироста производительности не дают - просто больше времени начинает тратиться на поднятие новых очередей, проход по дополнительным правилам "табличка-пайпы-тарифа", плюс есть неплохие шансы упереться хешсайзами.

 

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

 

Рекомендую почитать на досуге "Dummynet revisited" от Марты Карбоне и Луиджи Риццо, они очень круто объясняют почему и как работает дамминет.

 

PS всю последнюю неделю угробил на бенчмаркинг шейпа в различных позах и проявлениях (даже про altq прастигоспади задумался) - таки наиболее приемлемый вариант получился с табларгом поюзерно.

[smokenet 0]

Ну, мат часть не учил, потому как со временем совсем напряги.

Предположение мое основывается на визуальной (cacti) зависимости загрузки проца от кол-ва маков в сети и никак не совпадающей с нагрузкой на канал.

Для меня было неожиданностью насколько каждое правило в фаерволе нагружает систему в целом.

 

p.s. Собственно нагрузка колеблется от 15% до 30% Вместо 20%-100%.

[nightfly 1 241]

Да. На задачах ната-шейпа более доминирует на самом деле pps. Рост нагрузки при увеличении количества правил ipfw идет почти по экспоненте.

[Inzevision 1]

Тема уже старая, но всё же отпишусь. У меня такое случилось вчера, когда я надумал сегментировать сеть и собрал все VLAN в bridge на фряхе. И тут полезли грабли.

named[44835]: client 111.111.155.170#56009: error sending response: not enough free resources

Как результат, клиент не резолвит адреса и не имеет http.

Если ifconfig bridge0 down && ifconfig bridge up нормально работает минут 10, потом опять...

Пришлось откатиться до предыдущей логики работы.

До сих пор не могу понять, что фряхе не понравилось. 

Со старой схемой пропускает гигабит трафика без проблем, а тут такое...

[greyshadow 22]

А что тут думать - если просто бридж... для начала вы из фряхи сваяли неуправляемый свич, и все вланы у вас стали одним большим вланом

[Lambert 5]

ну дык, терминировать виланы - тоже ресурсы нужны