https://www.opennet.ru/openforum/vsluhforumID1/81005.html Есть пища к размышлению. Имеется сервачок под Linux, который занимается роутингом. Схема примерно такова:<br>есть сетевой интерфейс, на него приезжает 4 влана 802.1q. Один из них "наружу", три "внутрь". Стоит задача ограничить суммарно проходящий трафик снаружи внутрь и обратно для всех (подсети известны) кроме определенного списка адресов.<br>Для решения задачи используется ifb и htb. Входящий и исходящий траф по трем внутренним вланам заруливается соответственно на ifb0 и ifb1. Там висят шейпера htb. А в правилах tc filter.... до заворота общего трафика в классы идет несколько accept для тех адресов, которые не требуется шейпить. Акцепт примерно такой:<br>/usr/sbin/tc filter add dev $ifname parent 2: protocol ip u32 match ip dst $ipaddr action continue<br><br>Пока через сервачок суммарный пробегающий трафик в обе стороны не превышает 70 Мбит. (pps еще не отрисовал - сегодня займусь) При этом нагрузка на процессор иногда доползает до 50%. Проц - старенький Celeron 2.8 GHz. Отпрофилировал систему при разной нагрузке - https://www.opennet.ru/openforum/vsluhforumID1/81005.html#6 Tue, 08 Jul 2008 08:37:22 GMT &gt;&gt;&gt;значится ищем где он используется (ну например в iptables в -m state) <br>&gt;&gt;&gt;<br>&gt;&gt;&gt;и оптимизируй правила <br>&gt;&gt;<br>&gt;&gt;Наверняка NAT всё сжирает, что вполне предсказуемо. <br>&gt;<br>&gt;Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего <br>&gt;мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно. <br>&gt;<br><br>ну для начала советую посмотреть в modules.dep на предмет того,<br>что зависит от conntrack<br> https://www.opennet.ru/openforum/vsluhforumID1/81005.html#5 Mon, 07 Jul 2008 20:17:38 GMT &gt;&gt;значится ищем где он используется (ну например в iptables в -m state) <br>&gt;&gt;<br>&gt;&gt;и оптимизируй правила <br>&gt;<br>&gt;Наверняка NAT всё сжирает, что вполне предсказуемо. <br><br>Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно.<br> https://www.opennet.ru/openforum/vsluhforumID1/81005.html#4 Mon, 07 Jul 2008 20:15:42 GMT &gt;значится ищем где он используется (ну например в iptables в -m state) <br>&gt;<br>&gt;и оптимизируй правила <br><br>Наверняка NAT всё сжирает, что вполне предсказуемо.<br> https://www.opennet.ru/openforum/vsluhforumID1/81005.html#3 Mon, 07 Jul 2008 14:50:21 GMT &gt;&gt;а что тут сказать - так сетевой стек написан. единственный способ - <br>&gt;&gt;оптимизировать <br>&gt;&gt;классификатор (например на основе статистики). что касается conntrack, то не совсем <br>&gt;&gt;понятно при чем он здесь. <br>&gt;<br>&gt;Контрак при том, что он на втором месте после u32: <br>&gt;4697740 11.6008 cls_u32 <br>&gt;3538074 8.7371 nf_conntrack <br><br>ну опять-таки - оптимизировать модуль ты скорее всего не в состоянии,<br>значится ищем где он используется (ну например в iptables в -m state)<br>и оптимизируй правила<br><br> https://www.opennet.ru/openforum/vsluhforumID1/81005.html#2 Fri, 04 Jul 2008 07:54:15 GMT &gt;а что тут сказать - так сетевой стек написан. единственный способ - <br>&gt;оптимизировать <br>&gt;классификатор (например на основе статистики). что касается conntrack, то не совсем <br>&gt;понятно при чем он здесь. <br><br>Контрак при том, что он на втором месте после u32:<br>4697740 11.6008 cls_u32<br>3538074 8.7371 nf_conntrack<br> https://www.opennet.ru/openforum/vsluhforumID1/81005.html#1 Fri, 04 Jul 2008 06:29:27 GMT а что тут сказать - так сетевой стек написан. единственный способ - оптимизировать<br>классификатор (например на основе статистики). что касается conntrack, то не совсем<br>понятно при чем он здесь.<br>