Jump to content
Калькуляторы

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

Имеем: 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 мбит.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

#!/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 правил получаются...

Share this post


Link to post
Share on other sites

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

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

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

Edited by SiXeD

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

 

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

Edited by SiXeD

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

Почему тогда простой шейпер с хэшами без 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 by photon

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

Share this post


Link to post
Share on other sites
Да, ускорит работу скрипта на 2 секунды, но в самом шейпере роли не какой не сыграет.

Я знаю.

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this