Baneff

Где тут речь была о пакетном фильтре? Он и на фре паралелится. Речь была о шейпере. Шейпер в tc многопоточный? Не делайте вид, что не понимаете разницы. И да, проще посоветовать человеку перейти на ratelimit и это не потому, что человек этот тупой, а потому что другого решения проблемы просто нет, по крайней мере там в обсуждении его никто не предложил.

Смеялся. Пару месяцев назад на известном вражеском форуме обсуждалась тема "tc + centos 7 грузят процессор под 100%". Так вот, это вам ничего не напоминает? И главная рекомендация - перейдите на ipt_ratelimit и оно попустит. )))

И, кстати, tc ваш параллелится?

Возможно. Я человек старой закалки и меня учили, что должен быть шейпер и тогда юзеры довольны и не достают поддержку, ничего у них не дергается и не обрывается. Это как-то связано со скоростью по тарифному плану? Типа если скорость высокая, то шейпер не нужен? Лично я сомневаюсь, но могу ошибаться. Однако тогда у меня появляется вопрос о корректности многочисленных сравнений фри и линукса. Это мы значит сравниваем систему с полноценным шейпингом (действительно даёт нагрузку на систему) с системой с тупым полисингом (никакой нагрузки, любой копеечный свич умеет). Уважаемые линоксоводы и линукс

Ха, та кокой же это шейпер? Пакеты дропать много ума не надо, так и на фре можно без всяких там нагрузок. Шейпер под Дебиан есть? Ну хоть что-то близкое по функционалу к dummynet ?

А шейпер для IPoE под дебианом как реализован? Имхо шейпинг - узкое место в софтовых брасах. Терминация, нат, файервол, птичка при наличии x520-DA2 на любой системе до 10 гиг прокачается юзерского трафика при современной средней длине пакета около 900 байт. Поскольку всё отлично паралелится, а процессоры многоядерные и память сейчас копейки стоят на вторичном рынке. У FreeBSD вижу единственное узкое место - лучший шейпер этой системы dummynet не параллелится и это заставляет искать не столько многоядерные системы, сколько системы с максимальным быстродействием на одно ядро. Конечно, при прави

Ну спорить не буду, у каждого свои ньюансы, всякое может быть.

Ну вы пошли в обход вместо того, чтобы разобраться в чём дело. Я тоже из своего опыта: за много лет никогда не возникало необходимости включать pf и нагрузка как бы давно не 600кбит/с. Большую роль играет правильность составления правил ipfw. Всё должно быть логично, всё что можно - паковать в таблицы, минимум правил. А я встречал конфигурации, где были тысячи правил, так чего ж удивляться. Вот, например ниже график загрузки процессора (зелёный) и отдельно dummynet (синий) на довольно таки нагруженной машинке на боевом дежурстве. Никаких костылей, всё штатно.

И ещё, на всякий случай напомню, что dummynet - это только одна из частей ipfw, которая занимается только шейпингом, всё остальное в ipfw прекрасно параллелится.

От же ж. Ну почему он ущербный? Однопоточность его - это единственный недостаток, который работе не мешает. Он и в один поток шейпит прекрасно. Чем шейпить-то будете?

А зачем такой венигрет? Зачем сразу и ipfw и pf ? Там у вас наверное еще много сюрпризов, по одному выдаёте нагора?

Вы там в соседней теме интересуетесь как посмотреть сколько pf кушает. У вас там ещё и pf есть? Извините за любопытство.

Уж много раз твердили миру... Лучшая система - это та, которую лучше всего знает ваш админ. Да хоть бы и Микротик, тоже есть специалисты, которые собаку на нём съели. Ну нравится им и всё, чего уж тут. Но что интересно, обычно именно приверженцы линуха особо агрессивны в форумах. Вот например специалисты по Junos или IOS вообще обычно помалкивают, хотя им точно есть что сказать

О, линуксятники набежали ))) . Чего вы обижаетесь? Хорош ваш линух, хорош, зачем спорить? Но вам же сказали ясно, у человека FreeBSD, так уж сложилось, и эта тема не по линух и не про то, что круче. Иш как возбудились, услышав об однопоточном dummynet , но он хоть и однопоточный, но есть и работает прекрасно, вместе с быстрыми и удобными многопоточными ipfw и ядерным nat-ом. А по делу, то как работала фря, так и работает несмотря на крики и вопли "рок-н-ролл мёртв". Старый конь борозды не испортит. Я 20+ лет на фре и менять ничего не собираюсь, надеюсь доживу уже с ней. Если бы речь шла о выбо

Ну во первых - да, в эру анлимов особого смысла следить за трафиком юзеров не вижу ни для себя ни для самих юзеров. Если им надо - пусть сами считают, есть чем, слава Богу. Ну если провайдер особо жадный, то да, можно отслеживать и отстреливать наиболее потребляющих. Некоторые так делают, но каналы сейчас дешёвые, я считаю проще забить и забыть ибо сам подсчёт, контроль и отстрел тоже денег и нервов стОит. Другое дело - если по какой-то причине требуется детализация и архивирование трафика. Тогда - да, проблема. Любой коллектор даст большую нагрузку. Во вторых, методы есть. Например при схеме

Да, это тоже проходили, конечно убрать ipcad . Надо было сразу огласить весь список. Лично я не против варианта "всё в одном", но некоторые вещи таки не стОит. А оно надо вообще, траффик мониторить? Кроме того есть и другие методы.

Ещё добавлю по поводу измерения нагрузки на ядра и процессы. Да, есть штатный top и в портах есть atop удобный и логи пишет. Есть в портах ещё какие-то утильки подобные. Но в своё время писали в форумах, что они неправильно показывают загрузку. Не знаю правильно или неправильно, сравнивать лень было, но была поставлена задача нарисовать с помощью системы mrtg (есть в портах) точно правильный график общей средней загрузки по всем ядрам и процессам и отдельно, как самый критичный, график загрузки dummynet. Оказалось, что самая первичная и самая точная информация о загрузке выдается в системных п

Отвечу тут на обращение в личку, может ещё кому пригодится. По поводу привязки процессов к ядрам. к ядрам. По состоянию на FreeBSD 11 . В 12 и 13 возможно что-то поменялось, не знаю, надо проверять. Наши эксперименты привели к отрицательному результату: попытка привязать dummynet или прерывания к ядрам ничего не улучшили, а может даже и ухудшили ситуацию. Система сама достаточно хорошо рапределяет нагрузку по ядрам в автомате, без ручного управления, поэтому в результате мы от привязки отказались. По поводу dummynet есть в нюансы. Во первых, надо учитывать, что dum

Ну сам-то ipfw сильно систему не грузит, это надо специально постараться. Если там максимум несколько десятков правил с правильной логикой последовательности и с упаковкой данных в таблицы, то всё будет ок. Штатный ядерный NAT тоже не должен создавать большой нагрузки по идее. А вот штатный шейпер dummynet может легко пригрузить, да. Ну и потом систему грузит не так скорость, как кол-во пакетов в сек pps, котрые через систему пролетают? То есть если летит куча мелких пакетов, то это грузит больше. Но это ж азы, я так, на всякий случай.

Это фантастика какая-то. Ищите узкое место ибо 500мбит/с должно даже на одной встроенной карт работать, а не то что на лагге из 4-х интеловских карт. Смотрите загрузку процессора поядерно (top может показівать неверно!), смотрите есть ли потери пакетов, смотрите, какой именно процесс садит производительность, смотрите действительно ли приём и передача пакетов равномерно распределяются по физическим интерфейсам. Роутинг - это что? Есть BGP или просто статика? Нат, шейпер, файервол вполне могут садить всё. На чём сделано? Штатно, на ipfw? Ой, да тут столько вариантов может быть, что даже тяжело

Да, конечно, то что можно грузить модулями можете грузить. Это я по привычке. Хотя ipfw, если вы его используете, насколько я помню, в виде подгружаемого модуля до сих пор неполнофункциональный. Я до сих пор по убираю все лишнее из ядра и мира, ибо это опять стало актуально на виртуальных хостингах, там за память и ядра платить надо, а я жадный Да, системные переменные сильно изменены с 12-й версии и даже драйвера интеловских сетевух переименовали. igb уже там нету, пичалька.

Это хорошо, что 11-я, в 12-й уже всё поменялось. Так что наш старый конфиг должен по идее лечь нормально. Вот что откопал. Почему именно так - хз, я не помню уже. Возможно не до конца оптимально, но работало. Ниже только то, что касается сетевой подсистемы. > cat /sys/amd64/conf/AMD64 cpu HAMMER ident AMD64 options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options IPFIREWALL_DEFAULT_TO_ACCEPT options DUMMYNET options IPDIVERT options IPF

Чипы правильные. По поводу карт HP ничего сказать не могу, мы всегда ставили только родные Intel. Молитесь, чтобы стандартные драйвера подошли и чтобы HP ничего там не добавили полезного с их точки зрения, типа совместимости только с родными модулями. А так - всё по идее должно получиться. Далее. Какая версия фри? Конфиги зависят.

Ну тогда если будет правильная интеловская четырёхпортовка или правильная 10-гиговая карта, то на 8 ядер нагрузка должна быть более-менее равномерная. Есть ещё мнение, что двухпроцессорная система будет в качестве молотилки медленнее, чем даже если из неё просто вытянуть второй процессор. Типа за счёт накладных расходов по пересылке данных между банками памяти, которые таки привязаны к процессорам будут тормоза и один процессор справится лучше. Не могу ни подтвердить ни опровергнуть, сам лично не проверял, но встречал такое мнение неоднократно. Какую конкретно карту купили,

Я не Кеша, но всё же. А что тут можно сделать? Да, отсосать и прикупить канал пошире и новую оборудку. В первый раз что ли? Я прекрасно помню, как несколько лет назад вышла новая версия торента и трафик у провов резко возрос. Сколько было криков, стонов и даже попыток сорвать денег с авторов программы или заблокировать торрент вообще. И что? Отсосали, расширили и прикупили ибо провайдер всегда крайний и всё, что он может - это попытаться поднять цены, если конкурентная остановка позволяет, попытаться минимизировать расходы или продаться более крупному игроку. Так и сейчас. Можно взять партнёр