Linux, HTB, высокая загрузка ЦПУ

[Heggi]

Имеем: 2.6.34-gentoo-r12 #6 SMP Mon Dec 13 10:58:34 YEKT 2010 x86_64 Intel® Xeon® CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux

Шейпер на Hash-таблицах (согласно мануалу, ссылка на который тут пролетала, таблица 256*256, 2 младших октета IP адреса, HTB)

Нагрузка 450мбит суммарно, 80kpps.

Загрузка CPU - 80% (Soft interrupt), дрова на сеть - ядерные, потоки прибиты по ядрам равномерно (нагрузка тоже равномерная)

Сама сеть: Intel Corporation 82575EB Gigabit Network Connection (rev 02) 2 штуки.

 

Проблема: в ближайшее время планируется увеличение канала, расширение тарифов, т.е. железка просто загнется.

Отключение шейпера снижает нагрузку до 5% (SI), т.е. основная трабла в шейпере.

Как возможно оптимизировать?

 

Тарифы в основном 2-8 мбит.

[photon]

Чтобы разобраться, нужно видеть правила. Подозреваю, что у вас пакеты не попадают в хэши, а проходят последовательно по всем фильтрам.

[SiXeD]

2.6.30-gentoo-r5 #1 x86_64 Intel® Xeon® CPU E5405 @ 2.00GHz GenuineIntel GNU/Linux

поток как и у тебя 400-500 мбит

проц в пике нагрузки 20%

тарифы от 256кбит до 50 мбит

 

надо смотреть структуру шейпера, возможно есть очень длинные цепочки

[Heggi]

Код, инициализирующий шейпер.

 

#!/sbin/runscript

depend() {
       need net
       provide tcinit
}

TC=/sbin/tc
INT="eth0.99" #Internal Interface
DEVIN="ifb0"    #IFB for ingress for users
DEVOUT="ifb1"   #IFB for egress for users

start() {
       ebegin "Starting TC"
       ip link set dev $DEVIN up
       ip link set dev $DEVOUT up
       $TC qdisc add dev $INT root handle 2:0 prio
       $TC filter add dev $INT parent 2:0 protocol ip u32 \
           match u32 0 0 flowid 2:0 action mirred egress redirect dev $DEVIN
       $TC qdisc add dev $INT handle ffff: ingress
       $TC filter add dev $INT parent ffff: protocol ip prio 2 u32 \
           match u32 0 0 flowid ffff: action mirred egress redirect dev $DEVOUT

       echo "root qdisc"
       $TC qdisc add dev $DEVIN root handle 1:0 htb default 90
       $TC qdisc add dev $DEVOUT root handle 3:0 htb default 90
       $TC class add dev $DEVIN parent 1:0 classid 1:1 htb rate 1000Mbit
       $TC class add dev $DEVOUT parent 3:0 classid 3:1 htb rate 1000Mbit

       $TC qdisc add dev $DEVIN parent 1:1 sfq perturb 10
       $TC qdisc add dev $DEVOUT parent 3:1 sfq perturb 10

       echo "Creating hashing tables..."
       $TC filter add dev $DEVIN parent 1:0 prio 10 protocol ip u32
       $TC filter add dev $DEVOUT parent 3:0 prio 10 protocol ip u32

       echo "tables:"
       for ((i=1; i <= 256; i++))
       do
           $TC filter add dev $DEVIN parent 1:0 prio 10 handle $i: protocol ip u32 divisor 256
           $TC filter add dev $DEVOUT parent 3:0 prio 10 handle $i: protocol ip u32 divisor 256
       done

       echo "filters by networks (16 byte at header):"
       for ((i=1; i<=256; i++))
       do
           $TC filter add dev $DEVIN protocol ip prio 10 parent 1:0 u32 ht 800:: \
               match ip dst 10.193.$[i-1].0/24 link $i: hashkey mask 0x000000ff at 16
           $TC filter add dev $DEVOUT protocol ip prio 10 parent 3:0 u32 ht 800:: \
               match ip src 10.193.$[i-1].0/24 link $i: hashkey mask 0x000000ff at 12
       done

       eend 0
}

 

А так добавляются правила:

#!/bin/bash

TC=/sbin/tc

parse()
{
   IP0=$3
   IP1=$(( ${3} + 1 ))
   IP2=$4
}

parse `echo $1 | sed 's/[-\.\+]/ /g'`
IPHEX=`printf "%.x" $IP2`
CLASSID=`printf "%.x%.2x" $IP0 $IP2`

DATE=`date +%k`
if ((${DATE}>=1 && ${DATE}<8)); then  #Make Night
   RATE=$3
else
   RATE=$2
fi

$TC filter replace dev ifb0 protocol ip parent 1:1 pref 10 handle ${IP1}:${IPHEX}:800 u32 ht ${IP1}:${IPHEX}: match ip dst $1 flowid 1:${CLASSID}
$TC filter replace dev ifb1 protocol ip parent 3:1 pref 10 handle ${IP1}:${IPHEX}:800 u32 ht ${IP1}:${IPHEX}: match ip src $1 flowid 3:${CLASSID}

$TC class replace dev ifb0 parent 1:1 classid 1:${CLASSID} htb rate ${RATE}Kbit quantum 3000
$TC class replace dev ifb1 parent 3:1 classid 3:${CLASSID} htb rate ${RATE}Kbit quantum 3000

 

Судя по всему цепочки до 256 правил получаются...

[SiXeD]

256 подсетей, 256 правил итого 65536,

попробуй убрать лишние подсети если их не используешь, хотябы

for ((i=1; i<=128; i++))

Edited June 15, 2011 by SiXeD

[2c2i]

Нужно сделать хеширование в два этапа, сначала с маской 0x0000ff00 а потом 0x000000ff

[SiXeD]

Нужно сделать хеширование в два этапа, сначала с маской 0x0000ff00 а потом 0x000000ff

можно, только не понятно, зачем???

match ip dst 10.193.$[i-1].0/24

чем это не устраивает?

 

добавлено: Есть ли на этой тачке запущенный NAT правила в iptable -t mangle и стоит ли сенсор сбора данных о трафике????

Edited June 15, 2011 by SiXeD

[vitalyb]

можно, только не понятно, зачем???

потому что иначе сделать хеширование по >256 нельзя

[Heggi]

NAT был и остался (для отдельной подсети, которая этим шейпером не шейпится). Сейчас юзерам раздаем белые IP, которые соответственно не натятся.

Возможно стоит избавиться от ifb0 и ifb1 (NAT уже не нужен. Хотя не думаю, что они как-то повлияют на производительность)

Нетфлоу собирается ipcad через ULOG

 

Правил в iptables - 5 в цепочке FORWARD.

[photon]

В результате выяснилось, что мы имеем дело с чудо-комбайном, а не с шейпером. Почему тогда вопрос стоит об оптимизации именно шейпера, а, например, не о переходе с ipcad на Netflow-модуль для iptables? Во-первых, нужно посмотреть через oprofile, что именно грузит процессор, и во-вторых нужно перенести часть функций на другие машины.

Edited June 15, 2011 by photon

[Heggi]

В результате выяснилось, что мы имеем дело с чудо-комбайном, а не с шейпером. Почему тогда вопрос стоит об оптимизации именно шейпера, а, например, не о переходе с ipcad на Netflow-модуль для iptables? Во-первых, нужно посмотреть через oprofile, что именно грузит процессор, и во-вторых нужно перенести часть функций на другие машины.

 

В первом сообщении русским по белому написано, что если вырубить шейпер в ЧНН - загрузка ЦПУ не превышает 5% (при этом канал в полочку, ппс тоже резко вырастают).

Отключение нетфлоу и т.д. не вызывают аналогичной реакции.

[photon]

Почему тогда простой шейпер с хэшами без NAT и Netflow работает у многих практически на аппаратных скоростях? Проблема в том, что используется нестандартная конфигурация, где задействовано сразу много подсистем ядра, и определить из-за чего именно возникает узкое место не так просто, как кажется. Как уже предлагалось, нужно создавать хэш-фильтры только для тех сетей, которые реально используются, а не для 0-255. Два цикла, где i пробегает одни и те же значения, можно объединить.

 

       for ((i=1; i <= $imax; i++))
       do
           $TC filter add dev $DEVIN parent 1:0 prio 10 handle $i: protocol ip u32 divisor 256
           $TC filter add dev $DEVOUT parent 3:0 prio 10 handle $i: protocol ip u32 divisor 256
           $TC filter add dev $DEVIN protocol ip prio 10 parent 1:0 u32 ht 800:: \
               match ip dst 10.193.$[i-1].0/24 link $i: hashkey mask 0x000000ff at 16
           $TC filter add dev $DEVOUT protocol ip prio 10 parent 3:0 u32 ht 800:: \
               match ip src 10.193.$[i-1].0/24 link $i: hashkey mask 0x000000ff at 12
       done

Псеводустройства тоже снижают производительность, поэтому NAT и Netflow лучше все-таки вынести на другую машину. Если есть желание, можно сделать вложенные хэши по маскам 0x0000ff00 и 0x000000ff, это уменьшит количество правил, которые проходит каждый пакет, но и усложнит нумерацию параметров, скрипт придется значительно переписать.

Edited June 15, 2011 by photon

[SiXeD]

photon ты 4 раза редактировал свой пост, я замучился его перечитывать.

 

Два цикла, где i пробегает одни и те же значения, можно объединить.

Да, ускорит работу скрипта на 2 секунды, но в самом шейпере роли не какой не сыграет.

 

Heggi, Делай хоть что нибудь, на теории далеко не уедешь.

[photon]

Да, ускорит работу скрипта на 2 секунды, но в самом шейпере роли не какой не сыграет.

Я знаю.

[2c2i]

можно, только не понятно, зачем???

match ip dst 10.193.$[i-1].0/24

чем это не устраивает?

 

для пакета из сети 10.193.127 будет 127 проверок прежде чем он попадет в нужную хештаблицу. Если делать два уровня - две проверки.

[Heggi]

Убрал лишние подсети (осталось около 30 подсетей, не по порядку), более нагруженные сети перенес в начало цепочки.

Нагрузка заметно упала, посмотрим что будет в ЧНН