форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Уменьшение нагрузки CPU на Linux-роутере."

Сообщение от heap 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 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 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]