> Система выполняет свои фугкции полностью и ни один компонент не является
> узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе
> чисто юзерский).скажите, лично вы роутили 10 гигабит на PC?
для описанной вами в статье задаче достаточно dir-620 + openwrt.
хотя, раз вы всё пытаетесь оценить мой уровень, то в 2010 году вы задавали такие вопросы:
https://www.opennet.ru/openforum/vsluhforumID1/88075.html
>> уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать
>> свою точку зрения. Если вы считаете, что время state lookup в
>> pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав
>> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).
> Зависит, но не так критично как вы думаете. Чисто из практики.
чисто из практики - это на forum.nag.ru
там вопрос выбора пакетного фильтра затёрт до дыр, даже профайлили его через hwpmc.
>По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000
> ПФ будет нормально работать и не "умрет" как вы пишите.
я писал про 600k стейтов. это в 60 раз больше дефолта, который вы озвучили.
600к набираются достаточно легко в сети не очень большого провайдера.
>Но просто не будет создавать новые подключения.
как мило. "дорогой пользователь, вы не можете сходить на любимый вконтактик, т.к. у нас на
NAS исчерпан лимит стейтов".
> Видел системы, построеные не мной, где кол-во было ограничено
> 200к и проблем с нагрузкой не было.
я ещё раз напоминаю про 600k стейтов :)
вообще, на стенде я создавал ~ 2млн стейтов.
>> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
>> это несколько иначе).
> Во freebsd скоро совсем будет иначе. Имею ввиду PF SMP friendly
> :-)
1)до этого далеко
2)на текущий момент всё и так работает в однопоточном режиме
3)glebius довольно сильно переписывает pf, так что скорее будет openbsd pf и freebsd pf, достаточно сильно между собой отличающиеся.
