The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Уменьшение нагрузки CPU на Linux-роутере."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

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

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от Z0termaNN (ok) on 04-Июл-08, 10:29 
а что тут сказать - так сетевой стек написан. единственный способ - оптимизировать
классификатор (например на основе статистики). что касается conntrack, то не совсем
понятно при чем он здесь.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от heap email on 04-Июл-08, 11:54 
>а что тут сказать - так сетевой стек написан. единственный способ -
>оптимизировать
>классификатор (например на основе статистики). что касается conntrack, то не совсем
>понятно при чем он здесь.

Контрак при том, что он на втором месте после u32:
4697740 11.6008 cls_u32
3538074  8.7371 nf_conntrack

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от Z0termaNN (ok) on 07-Июл-08, 18:50 
>>а что тут сказать - так сетевой стек написан. единственный способ -
>>оптимизировать
>>классификатор (например на основе статистики). что касается conntrack, то не совсем
>>понятно при чем он здесь.
>
>Контрак при том, что он на втором месте после u32:
>4697740 11.6008 cls_u32
>3538074  8.7371 nf_conntrack

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

4. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от Аноним (??) on 08-Июл-08, 00:15 
>значится ищем где он используется (ну например в iptables в -m state)
>
>и оптимизируй правила

Наверняка NAT всё сжирает, что вполне предсказуемо.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от heap email on 08-Июл-08, 00:17 
>>значится ищем где он используется (ну например в iptables в -m state)
>>
>>и оптимизируй правила
>
>Наверняка NAT всё сжирает, что вполне предсказуемо.

Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Уменьшение нагрузки CPU на Linux-роутере."  
Сообщение от Z0termaNN (ok) on 08-Июл-08, 12:37 
>>>значится ищем где он используется (ну например в iptables в -m state)
>>>
>>>и оптимизируй правила
>>
>>Наверняка NAT всё сжирает, что вполне предсказуемо.
>
>Судя по профайлеру все-таки не НАТ. Да и приходится на НАТ всего
>мегабитика 2-3. У меня похожие машинки и больше 30-40 НАТили успешно.
>

ну для начала советую посмотреть в modules.dep на предмет того,
что зависит от conntrack

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2023 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру