Исходное сообщение
"Уменьшение нагрузки CPU на Linux-роутере." Отправлено heap, 03-Июл-08 11:55
Есть пища к размышлению. Имеется сервачок под Linux, который занимается роутингом. Схема примерно такова: есть сетевой интерфейс, на него приезжает 4 влана 802.1q. Один из них "наружу", три "внутрь". Стоит задача ограничить суммарно проходящий трафик снаружи внутрь и обратно для всех (подсети известны) кроме определенного списка адресов. Для решения задачи используется ifb и htb. Входящий и исходящий траф по трем внутренним вланам заруливается соответственно на ifb0 и ifb1. Там висят шейпера htb. А в правилах tc filter.... до заворота общего трафика в классы идет несколько accept для тех адресов, которые не требуется шейпить. Акцепт примерно такой: /usr/sbin/tc filter add dev $ifname parent 2: protocol ip u32 match ip dst $ipaddr action continue Пока через сервачок суммарный пробегающий трафик в обе стороны не превышает 70 Мбит. (pps еще не отрисовал - сегодня займусь) При этом нагрузка на процессор иногда доползает до 50%. Проц - старенький Celeron 2.8 GHz. Отпрофилировал систему при разной нагрузке - вот первые несколько строк opreport: CPU: P4 / Xeon, speed 2800.12 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 GLOBAL_POWER_E...|   samples|      %| ------------------ 19736786 52.2662 vmlinux-2.6.25.5-1.1-pae   4383294 11.6077 cls_u32   3298304  8.7344 nf_conntrack   2180856  5.7753 e100   1926319  5.1012 sch_htb   1133425  3.0015 ip_tables    845431  2.2388 sch_sfq    762497  2.0192 8021q    723182  1.9151 oprofiled    484649  1.2834 iptable_nat    330576  0.8754 ifb -------------------------------------------------------- CPU: P4 / Xeon, speed 2800.12 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 100000 GLOBAL_POWER_E...|   samples|      %| ------------------ 21182227 52.3082 vmlinux-2.6.25.5-1.1-pae   4697740 11.6008 cls_u32   3538074  8.7371 nf_conntrack   2337399  5.7721 e100   2067064  5.1045 sch_htb   1216320  3.0036 ip_tables    906336  2.2381 sch_sfq    818557  2.0214 8021q    775152  1.9142 oprofiled    519721  1.2834 iptable_nat    355196  0.8771 ifb Как видно наиболее прожорлив классификатор u32 и conntrack. Недалеко отстали драйвер сетевушки и шедулеры. Какие могут быть полезные идеи в плане оптимизации работы этих узких мест, чтобы сервачок мог прожевать как можно больше трафика?