URL: https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 81005
[ Назад ]

Исходное сообщение
"Уменьшение нагрузки 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. Недалеко отстали драйвер сетевушки и шедулеры. Какие могут быть полезные идеи в плане оптимизации работы этих узких мест, чтобы сервачок мог прожевать как можно больше трафика?

Содержание

Уменьшение нагрузки CPU на Linux-роутере.,Z0termaNN, 10:29 , 04-Июл-08
- Уменьшение нагрузки CPU на Linux-роутере.,heap, 11:54 , 04-Июл-08
  - Уменьшение нагрузки CPU на Linux-роутере.,Z0termaNN, 18:50 , 07-Июл-08
    - Уменьшение нагрузки CPU на Linux-роутере.,Аноним, 00:15 , 08-Июл-08
      - Уменьшение нагрузки CPU на Linux-роутере.,heap, 00:17 , 08-Июл-08
        
        Уменьшение нагрузки CPU на Linux-роутере.,Z0termaNN, 12:37 , 08-Июл-08

Сообщения в этом обсуждении

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено Z0termaNN , 04-Июл-08 10:29

а что тут сказать - так сетевой стек написан. единственный способ - оптимизировать
классификатор (например на основе статистики). что касается conntrack, то не совсем
понятно при чем он здесь.

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено heap , 04-Июл-08 11:54

>а что тут сказать - так сетевой стек написан. единственный способ -
>оптимизировать
>классификатор (например на основе статистики). что касается conntrack, то не совсем
>понятно при чем он здесь.
Контрак при том, что он на втором месте после u32:
4697740 11.6008 cls_u32
3538074 8.7371 nf_conntrack

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено Z0termaNN , 07-Июл-08 18:50

>>а что тут сказать - так сетевой стек написан. единственный способ -
>>оптимизировать
>>классификатор (например на основе статистики). что касается conntrack, то не совсем
>>понятно при чем он здесь.
>
>Контрак при том, что он на втором месте после u32:
>4697740 11.6008 cls_u32
>3538074 8.7371 nf_conntrack
ну опять-таки - оптимизировать модуль ты скорее всего не в состоянии,
значится ищем где он используется (ну например в iptables в -m state)
и оптимизируй правила

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено Аноним , 08-Июл-08 00:15

>значится ищем где он используется (ну например в iptables в -m state)
>
>и оптимизируй правила
Наверняка NAT всё сжирает, что вполне предсказуемо.

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено heap , 08-Июл-08 00:17

>>значится ищем где он используется (ну например в iptables в -m state)
>>
>>и оптимизируй правила
>
>Наверняка NAT всё сжирает, что вполне предсказуемо.
Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно.

"Уменьшение нагрузки CPU на Linux-роутере."
Отправлено Z0termaNN , 08-Июл-08 12:37

>>>значится ищем где он используется (ну например в iptables в -m state)
>>>
>>>и оптимизируй правила
>>
>>Наверняка NAT всё сжирает, что вполне предсказуемо.
>
>Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего
>мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно.
>
ну для начала советую посмотреть в modules.dep на предмет того,
что зависит от conntrack