Перейти к содержимому
Калькуляторы
  

398 пользователей проголосовало

  1. 1. Ось для бордера


Vote. Система для бордера Кто что держит на бордерах?

Ответить

telecom   

telecom
Опубликовано (изменено) · Жалоба

...

Для интересующихся распараллеливанием: вот из последних снимков более наглядно по процам:

...

Интересуюсь.

Как TC по ядрам раскидывали?

Изменено пользователем telecom

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано (изменено) · Жалоба

Основную работу выполняет RPS, сами по себе пакетные фильтры и шейперы TC распараллеливаются в контексте сетевого стека, по пути следования skb.

Наборы фильтров TC прибиваются "головой" (SSG) к конкретным интерфейсам PPP/IFB. В ядро докинуто руками несколько оптимизирующих патчей.

 

В качестве эксперимента на отдельной площадке пробовал прибивать хитровыделанные правила TC к "большим" интерфейсам - при одинаковом числе проходимых фильтров и соответствующем разделении по классам работает не хуже, чем при прибивании к PPP, видимой глазу разницы по загрузке CPU замечено не было.

 

HTB, кстати, показал себя с очень плохой стороны - явные проблемы с распараллеливанием, неюзабельно. HFSC ведёт себя нормально.

Изменено пользователем Alex/AT

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

telecom   

telecom
Опубликовано · Жалоба

Про "несколько оптимизирующих" патчи можно подробнее?

И не смог с ходу мануал про HFSC нарыть... Не так часто его юзают, по сравнению с НТВ

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

martini   

martini
Опубликовано · Жалоба

а можно примерчик установки скорости 2000к на HFSC ?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано · Жалоба

2000к - это 2 Мбита?

Если да, то:

tc qdisc add dev $DEV root handle 1: hfsc
tc class add dev $DEV parent 1: classid $CLASS hfsc sc rate 2000000 ul rate 2000000
tc qdisc add dev $DEV parent $CLASS handle $HANDLE sfq

Мы пользуемся очередями SFQ на концевых классах. Ну и фильтром запихать трафик в класс.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

photon   

photon
Опубликовано (изменено) · Жалоба

HTB, кстати, показал себя с очень плохой стороны - явные проблемы с распараллеливанием, неюзабельно. HFSC ведёт себя нормально.

Странно, все время использую HTB, все процессоры нагружаются равномерно даже без irqbalance. Как вы определяете, что проблема с параллелизмом именно в этой дисциплине?

Изменено пользователем photon

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано (изменено) · Жалоба

Банально. Менялся HFSC на HTB в SSG, после этого нагрузка от softirq росла где-то втрое. По коду сложности алгоритмов сопоставимы, разница есть в пользу HFSC, но вряд ли троекратный рост можно объяснить этой разницей.

 

Надо бы было oprofile погонять, по-хорошему, но поскольку HFSC даёт ко всему прочему более стабильные параметры потока (с HTB правильное задание параметров, чтобы пропускную способность клиента не бросало из стороны в сторону - настоящее мучение, особенно когда верхний порог начинает превышать 10mbps), было решено не мучаться.

 

Сразу говорю - есть определённая специфика. Шейперы висят на pppX/ifbX, коих очень много (от одной до нескольких тысяч). Поэтому вполне возможно, что HTB загнивает именно в таких условиях.

Ну и на последних ядрах не тестировал, вполне возможно, что что-то починилось. Надо будет попробовать, если попробую - напишу результат.

Изменено пользователем Alex/AT

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

photon   

photon
Опубликовано (изменено) · Жалоба

Сразу говорю - есть определённая специфика. Шейперы висят на pppX/ifbX, коих очень много (от одной до нескольких тысяч). Поэтому вполне возможно, что HTB загнивает именно в таких условиях.

По идее, если для каждого юзера создается отдельный ppp-интерфейс, то для ограничения скорости в обе стороны на него можно повесить простой token bucket (tbf) и полисер. Зачем здесь классовые дисциплины?

Изменено пользователем photon

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

replicant   

replicant
Опубликовано · Жалоба

Сразу говорю - есть определённая специфика. Шейперы висят на pppX/ifbX, коих очень много (от одной до нескольких тысяч). Поэтому вполне возможно, что HTB загнивает именно в таких условиях.

По идее, если для каждого юзера создается отдельный ppp-интерфейс, то для ограничения скорости в обе стороны на него можно повесить простой token bucket (tbf) и полисер. Зачем здесь классовые дисциплины?

+ 1, тоже не понял зачем такая сложность и вообще как это к бордеру относится?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано (изменено) · Жалоба
+ 1, тоже не понял зачем такая сложность и вообще как это к бордеру относится?

Просто стоило начало ветки сначала прочитать:

Немножко не бордер - PPPoE-концентратор, но под определение "молотить терабайты трафика" подходит как нельзя лучше. На бордер (если бы не было аппаратного решения) - поставил бы почти то же самое.

Но к теме косвенно относится, потому что этот концентратор легким движением руки превращается в бордер (один из бордеров сидит на точно такой же сборке, только PPPoE/QinQ выключены). Интересовал выбор ОС, поэтому "молотилку" обсуждать вполне допустимо IMNSHO. Суть в терабайтах (петабайтах).

 

Зачем такая сложность? Затем, что на абонента может быть далеко не один класс трафика, причём в конкретном контексте подход аналогичен Cisco SSG/ISG, вешаются "сервисы". Да, и BGP Full view / Partial view при необходимости он тоже принимает, и фильтры вешаются, и policy routing делает. Если обсуждать дальше - лучше на самом деле перейти в другую ветку.

Изменено пользователем Alex/AT

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

andriyj   

andriyj
Опубликовано (изменено) · Жалоба 
FreeBSD 8.2-RELEASE-p1 #3: Mon May  2 21:15:32 EEST 2011
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM) i7 CPU         970  @ 3.20GHz (3245.01-MHz K8-class CPU)
............
real memory  = 2147483648 (2048 MB)
avail memory = 2056568832 (1961 MB)


#top -SPH

last pid: 80528;  load averages:  0.11,  0.16,  0.16             up 112+09:22:08 23:13:53
186 processes: 18 running, 123 sleeping, 2 stopped, 2 zombie, 41 waiting
CPU 0:   0.0% user,  0.0% nice,  2.9% system, 29.3% interrupt, 67.8% idle
CPU 1:   0.8% user,  0.0% nice,  2.1% system, 27.7% interrupt, 69.3% idle
CPU 2:   0.4% user,  0.0% nice,  2.9% system, 26.1% interrupt, 70.6% idle
CPU 3:   1.7% user,  0.0% nice,  1.3% system, 25.6% interrupt, 71.4% idle
CPU 4:   0.0% user,  0.0% nice,  0.4% system, 68.9% interrupt, 30.7% idle
CPU 5:   0.0% user,  0.0% nice,  0.0% system, 31.9% interrupt, 68.1% idle
CPU 6:   0.0% user,  0.0% nice,  0.8% system, 25.6% interrupt, 73.5% idle
CPU 7:   0.0% user,  0.0% nice,  0.0% system, 55.5% interrupt, 44.5% idle
CPU 8:   0.4% user,  0.0% nice,  1.7% system, 28.2% interrupt, 69.7% idle
CPU 9:   0.0% user,  0.0% nice,  0.8% system, 22.7% interrupt, 76.5% idle
CPU 10:  0.0% user,  0.0% nice,  1.7% system, 20.2% interrupt, 78.2% idle
CPU 11:  0.0% user,  0.0% nice,  0.0% system, 22.3% interrupt, 77.7% idle
Mem: 611M Active, 355M Inact, 665M Wired, 35M Cache, 213M Buf, 309M Free
Swap: 4059M Total, 4059M Free


# uptime
11:15PM  up 112 days,  9:24, 3 users, load averages: 0.20, 0.16, 0.16

# netstat -h -w 1
           input        (Total)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
     500K     0     0       319M       497K     0       303M     0
     502K     0     0       325M       500K     0       310M     0
     498K     0     0       320M       494K     0       303M     0
     503K     0     0       328M       499K     0       308M     0
     491K     0     0       326M       486K     0       304M     0
     489K     0     0       320M       486K     0       303M     0
     498K     0     0       329M       495K     0       311M     0
     490K     0     0       324M       485K     0       303M     0
     486K     0     0       325M       479K     0       301M     0
     493K     0     0       326M       488K     0       303M     0
     498K     0     0       318M       495K     0       298M     0
     498K     0     0       326M       495K     0       308M     0
     491K     0     0       321M       487K     0       302M     0
     496K     0     0       323M       489K     0       300M     0
     502K     0     0       323M       499K     0       307M     0
     504K     0     0       325M       500K     0       307M     0
     492K     0     0       319M       486K     0       299M     0
     485K     0     0       319M       481K     0       301M     0
     499K     0     0       323M       496K     0       308M     0
     492K     0     0       319M       489K     0       304M     0

Изменено пользователем andriyj

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

a-zazell   

a-zazell
Опубликовано · Жалоба 

FreeBSD 8.2-RELEASE-p1 #3: Mon May  2 21:15:32 EEST 2011
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM) i7 CPU         970  @ 3.20GHz (3245.01-MHz K8-class CPU)
............
real memory  = 2147483648 (2048 MB)
avail memory = 2056568832 (1961 MB)


#top -SPH

last pid: 80528;  load averages:  0.11,  0.16,  0.16             up 112+09:22:08 23:13:53
186 processes: 18 running, 123 sleeping, 2 stopped, 2 zombie, 41 waiting
CPU 0:   0.0% user,  0.0% nice,  2.9% system, 29.3% interrupt, 67.8% idle
CPU 1:   0.8% user,  0.0% nice,  2.1% system, 27.7% interrupt, 69.3% idle
CPU 2:   0.4% user,  0.0% nice,  2.9% system, 26.1% interrupt, 70.6% idle
CPU 3:   1.7% user,  0.0% nice,  1.3% system, 25.6% interrupt, 71.4% idle
CPU 4:   0.0% user,  0.0% nice,  0.4% system, 68.9% interrupt, 30.7% idle
CPU 5:   0.0% user,  0.0% nice,  0.0% system, 31.9% interrupt, 68.1% idle
CPU 6:   0.0% user,  0.0% nice,  0.8% system, 25.6% interrupt, 73.5% idle
CPU 7:   0.0% user,  0.0% nice,  0.0% system, 55.5% interrupt, 44.5% idle
CPU 8:   0.4% user,  0.0% nice,  1.7% system, 28.2% interrupt, 69.7% idle
CPU 9:   0.0% user,  0.0% nice,  0.8% system, 22.7% interrupt, 76.5% idle
CPU 10:  0.0% user,  0.0% nice,  1.7% system, 20.2% interrupt, 78.2% idle
CPU 11:  0.0% user,  0.0% nice,  0.0% system, 22.3% interrupt, 77.7% idle
Mem: 611M Active, 355M Inact, 665M Wired, 35M Cache, 213M Buf, 309M Free
Swap: 4059M Total, 4059M Free


# uptime
11:15PM  up 112 days,  9:24, 3 users, load averages: 0.20, 0.16, 0.16

# netstat -h -w 1
           input        (Total)           output
  packets  errs idrops      bytes    packets  errs      bytes colls
     500K     0     0       319M       497K     0       303M     0
     502K     0     0       325M       500K     0       310M     0
     498K     0     0       320M       494K     0       303M     0
     503K     0     0       328M       499K     0       308M     0
     491K     0     0       326M       486K     0       304M     0

 

Ого, это он у Вас 2.5 гигабита гоняет?? А сетевые какие и сколько если не тайна?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

andriyj   

andriyj
Опубликовано (изменено) · Жалоба

 

Ого, это он у Вас 2.5 гигабита гоняет?? А сетевые какие и сколько если не тайна?

 

 

Сетевых карт - 2 шт по 2 головы .

igb0@pci0:2:0:0:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb1@pci0:2:0:1:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb2@pci0:3:0:0:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb3@pci0:3:0:1:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet

 

Пока без агрегации.

Изменено пользователем andriyj

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

martini   

martini
Опубликовано (изменено) · Жалоба 

Linux shaper173 3.0.0-12-generic-pae
(probing every 0.500s), press 'h' for help
 input: /proc/net/dev type: rate
 \         iface                   Rx                   Tx                Total
 ==============================================================================
            eth1:         586.01 Mb/s          618.20 Mb/s            1.18 Gb/s
            eth2:         425.14 Mb/s          419.15 Mb/s          844.29 Mb/s
            eth3:         511.41 Mb/s          338.86 Mb/s          850.27 Mb/s
            eth4:         375.76 Mb/s          520.37 Mb/s          896.12 Mb/s
 ------------------------------------------------------------------------------
           total:           1.85 Gb/s            1.85 Gb/s            3.71 Gb/s

вечерами до 6Гбит доходит.

top - 01:21:53 up 9 days,  9:53,  2 users,  load average: 0.20, 0.14, 0.14
Tasks:  79 total,   4 running,  75 sleeping,   0 stopped,   0 zombie
Cpu0  : 30.0%us,  7.7%sy,  0.0%ni, 40.7%id,  0.0%wa,  0.0%hi, 21.7%si,  0.0%st
Cpu1  : 42.7%us, 14.7%sy,  0.0%ni, 27.7%id,  0.0%wa,  0.0%hi, 15.0%si,  0.0%st
Cpu2  : 18.6%us,  3.0%sy,  0.0%ni, 61.5%id,  4.3%wa,  0.0%hi, 12.6%si,  0.0%st
Cpu3  :  2.7%us,  1.7%sy,  0.0%ni, 81.3%id,  0.0%wa,  0.0%hi, 14.3%si,  0.0%st
Mem:   2053072k total,   667840k used,  1385232k free,    92980k buffers
Swap:        0k total,        0k used,        0k free,   283484k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
21444 root      20   0  5796 4324  916 S    1  0.2  58:32.41 speed-mon
  10 root      20   0     0    0    0 S    0  0.0  14:18.85 kworker/0:1
25695 root      20   0 10952 4312 1980 S    0  0.2   0:00.14 python
   1 root      20   0  5436 3980 1260 S    0  0.2   0:03.33 init
   2 root      20   0     0    0    0 S    0  0.0   0:00.00 kthreadd
   3 root      20   0     0    0    0 S    0  0.0   2:47.82 ksoftirqd/0
   5 root      20   0     0    0    0 R    0  0.0   0:56.71 kworker/u:0
   6 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/0
   7 root      RT   0     0    0    0 S    0  0.0   0:00.00 migration/1
   9 root      20   0     0    0    0 S    0  0.0   1:40.55 ksoftirqd/1

Изменено пользователем martini

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

a-zazell   

a-zazell
Опубликовано · Жалоба

Сетевых карт - 2 шт по 2 головы .

 

igb0@pci0:2:0:0:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet

...

 

Пока без агрегации.

 

А какие задачи выполняет? NAT, shaping ... ?? Просто в принципе есть ПОЧТИ тоже самое, но трафика в 3 раза меньше.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

andriyj   

andriyj
Опубликовано · Жалоба

 

 

 

А какие задачи выполняет? NAT, shaping ... ?? Просто в принципе есть ПОЧТИ тоже самое, но трафика в 3 раза меньше.

 

 

 

А какие задачи выполняет? NAT, shaping ... ?? Просто в принципе есть ПОЧТИ тоже самое, но трафика в 3 раза меньше.

 

1 карта обслуживает BRASы.

2.карта клиенты с статическими ІР адресами ( мелкие конторы , которые берут статику /30 /19 .... ). Скорость режим прямо на порту свича.

3,4 - аплинки

NAT есть, но клиентов с серыми ІР очень мало ( можно пересчитать на пальцах.) В основном все имеют белый адрес.

BGP - quagga принимаем фулл вю

Шейпинг через IPFW не используем.

Правила IPFW в основном для того чтобы закрыть "паразитный" трафик ( NETBIOS, SMTP от троянов ...)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

a-zazell   

a-zazell
Опубликовано · Жалоба

1 карта обслуживает BRASы.

2.карта клиенты с статическими ІР адресами ( мелкие конторы , которые берут статику /30 /19 .... ). Скорость режим прямо на порту свича.

3,4 - аплинки

NAT есть, но клиентов с серыми ІР очень мало ( можно пересчитать на пальцах.) В основном все имеют белый адрес.

BGP - quagga принимаем фулл вю

Шейпинг через IPFW не используем.

Правила IPFW в основном для того чтобы закрыть "паразитный" трафик ( NETBIOS, SMTP от троянов ...)

 

Спасибо, у нас немного больше в сторону NAT и shaper.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

t00r   

t00r
Опубликовано · Жалоба
http://forum.nag.ru/forum/index.php?showtopic=71822&view=findpost&p=666608

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

SmokerMan   

SmokerMan
Опубликовано · Жалоба

А где Mac OS X??? :-)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

telecom   

telecom
Опубликовано (изменено) · Жалоба

Да, от гипертрединга для задач роутинга/концентрации больше вреда, чем пользы. irqbalance используется.

 

Для интересующихся распараллеливанием: вот из последних снимков более наглядно по процам:

 

Tasks: 2142 total,   3 running, 2139 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.6%us,  2.9%sy,  0.0%ni, 66.8%id,  0.0%wa,  0.0%hi, 29.7%si,  0.0%st
Cpu1  :  5.1%us,  6.1%sy,  0.0%ni, 58.7%id,  0.0%wa,  0.0%hi, 30.1%si,  0.0%st
Cpu2  :  4.8%us,  3.5%sy,  0.0%ni, 74.6%id,  0.0%wa,  0.0%hi, 17.1%si,  0.0%st
Cpu3  :  1.3%us, 14.4%sy,  0.0%ni, 67.9%id,  0.0%wa,  0.0%hi, 16.3%si,  0.0%st
Cpu4  :  1.6%us, 17.9%sy,  0.0%ni, 62.9%id,  0.0%wa,  0.0%hi, 17.6%si,  0.0%st
Cpu5  :  1.0%us,  1.0%sy,  0.0%ni, 88.7%id,  0.0%wa,  0.0%hi,  9.3%si,  0.0%st
Cpu6  :  0.3%us,  0.6%sy,  0.0%ni, 54.8%id,  2.9%wa,  2.6%hi, 38.7%si,  0.0%st
Cpu7  :  1.9%us,  3.5%sy,  0.0%ni, 64.1%id,  0.0%wa,  1.6%hi, 28.8%si,  0.0%st
Cpu8  :  2.6%us, 11.9%sy,  0.0%ni, 69.1%id,  0.0%wa,  1.3%hi, 15.1%si,  0.0%st
Cpu9  :  2.7%us, 11.8%sy,  0.0%ni, 61.9%id,  0.0%wa,  0.6%hi, 23.0%si,  0.0%st
Cpu10 :  0.6%us, 13.8%sy,  0.0%ni, 63.5%id,  0.0%wa,  0.3%hi, 21.7%si,  0.0%st
Cpu11 :  0.0%us,  0.0%sy,  0.0%ni, 88.9%id,  0.0%wa,  1.0%hi, 10.2%si,  0.0%st
Mem:   8183116k total,  2407612k used,  5775504k free,   141976k buffers
Swap:  8387568k total,        0k used,  8387568k free,   370244k cached

 PID PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
4803 20   0 11396 1284  688 D 17.8  0.0   0:00.55 tc
4811 20   0 11396 1196  608 R 16.5  0.0   0:00.51 tc
4814 20   0 11036 3468  576 R 12.9  0.0   0:00.40 ifconfig
9219 20   0  9816 1384  472 S 10.0  0.0   1:15.63 irqbalance
4797 20   0  144m  12m 7104 S  3.2  0.2   0:00.10 ssg_wrapper
3517 20   0 16552 2888  972 R  2.6  0.0   0:01.19 top
4813 20   0  144m  12m 6896 S  2.6  0.2   0:00.08 ssg_coa
4766 20   0  144m  12m 7104 S  2.3  0.2   0:00.07 ssg_wrapper
   4 20   0     0    0    0 S  1.6  0.0   9:47.05 ksoftirqd/0
  22 20   0     0    0    0 S  1.6  0.0   7:12.58 ksoftirqd/6
26243 20   0  645m 3980 1064 S  1.3  0.0  18:17.55 radiusd
   7 20   0     0    0    0 S  1.0  0.0   7:32.32 ksoftirqd/1
2038 20   0 2906m 127m 6172 S  1.0  1.6  33:54.83 mysqld
  13 20   0     0    0    0 S  0.6  0.0   4:23.09 ksoftirqd/3
2665 20   0 29624 2788 2468 S  0.6  0.0   0:00.24 pppd
9133 20   0 29624 2108 1788 S  0.6  0.0   0:00.09 pppd
  10 20   0     0    0    0 S  0.3  0.0   5:34.59 ksoftirqd/2
  16 20   0     0    0    0 S  0.3  0.0   3:40.63 ksoftirqd/4
  19 20   0     0    0    0 S  0.3  0.0   2:48.02 ksoftirqd/5
  21 RT   0     0    0    0 S  0.3  0.0   0:00.69 migration/6
  24 RT   0     0    0    0 S  0.3  0.0   0:10.16 migration/7
  28 20   0     0    0    0 S  0.3  0.0   3:02.87 ksoftirqd/8
  37 20   0     0    0    0 S  0.3  0.0   1:51.27 ksoftirqd/11
  45 20   0     0    0    0 S  0.3  0.0   3:01.96 events/6
 367 20   0 29624 2588 2272 S  0.3  0.0   0:00.18 pppd
 553 20   0     0    0    0 S  0.3  0.0   6:10.52 md1_raid1
 618 20   0     0    0    0 S  0.3  0.0   0:59.57 jbd2/md1-8
1709 20   0  242m 1464  908 S  0.3  0.0   2:07.67 rsyslogd
1761 20   0 12104 4360  588 S  0.3  0.1  69:30.16 bird

 

 

 

 

 

У меня на новом тазике вот так:

 

20:39:52     CPU        %usr   %nice    %sys  %iowait   %irq   %soft   %steal  %guest  %idle
20:39:53     all        0,00    0,00    0,09    0,35    0,00    3,74    0,00    0,00   95,83
20:39:53       0        0,00    0,00    0,00    0,00    0,00    4,00    0,00    0,00   96,00
20:39:53       1        0,00    0,00    1,00    3,00    0,00    2,00    0,00    0,00   94,00
20:39:53       2        0,00    0,00    0,00    0,00    0,00    0,79    0,00    0,00   99,21
20:39:53       3        0,00    0,00    0,00    0,00    0,00    1,10    0,00    0,00   98,90
20:39:53       4        0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
20:39:53       5        0,00    0,00    0,00    0,00    0,00    1,00    0,00    0,00   99,00
20:39:53       6        0,00    0,00    0,00    0,00    0,00    1,71    0,00    0,00   98,29
20:39:53       7        0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
20:39:53       8        0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
20:39:53       9        0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
20:39:53      10        0,00    0,00    0,00    0,00    0,00    0,00    0,00    0,00  100,00
20:39:53      11        0,00    0,00    1,03    2,06    0,00   32,99    0,00    0,00   63,92

 

Особенно заметна нагрузка на последнем ядре второго проца (первая очередь интерфейса).

Что-то не докрутил. Критика приветствуется, помощь с благодарностью принимается)

Изменено пользователем telecom

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

telecom   

telecom
Опубликовано · Жалоба

Банально. Менялся HFSC на HTB в SSG, после этого нагрузка от softirq росла где-то втрое. По коду сложности алгоритмов сопоставимы, разница есть в пользу HFSC, но вряд ли троекратный рост можно объяснить этой разницей.

В пару раз точно. По сложности реализации HFSC легче и гибче.

 

поскольку HFSC даёт ко всему прочему более стабильные параметры потока (с HTB правильное задание параметров, чтобы пропускную способность клиента не бросало из стороны в сторону - настоящее мучение, особенно когда верхний порог начинает превышать 10mbps), было решено не мучаться.

Действительно, более гладкое ограничение. В HTB при скоростях выше 6-10 надо делать динамический burst

 

Сразу говорю - есть определённая специфика. Шейперы висят на pppX/ifbX, коих очень много (от одной до нескольких тысяч). Поэтому вполне возможно, что HTB загнивает именно в таких условиях. Ну и на последних ядрах не тестировал, вполне возможно, что что-то починилось. Надо будет попробовать, если попробую - напишу результат.

У меня абсолюто такая же специфика. Грабли полезли, как ни странно, после перехода с FC13 на Centos6. Проблема в значительно большем кол-ве прерываний на первой очереди. Поделитесь, плиз, идеями.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Alex/AT   

Alex/AT
Опубликовано (изменено) · Жалоба

Распределение по входящим очередям зависит от самого сетевого адаптера (и, возможно, драйвера), если Вы об аппаратных очередях - надо крутить его. Если Вы об RPS - он в RH6.1 неюзабелен, будет бросать всё на первый CPU в списке, надо патчить.

Изменено пользователем Alex/AT

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

telecom   

telecom
Опубликовано · Жалоба

Переход с HTB на HFSC кроме снижения нагрузки и более гладкой нарезке ничего не дает в плане "распараллеливания".

 

Распределение по входящим очередям зависит от самого сетевого адаптера (и, возможно, драйвера), если Вы об аппаратных очередях - надо крутить его. Если Вы об RPS - он в RH6.1 неюзабелен, будет бросать всё на первый CPU в списке, надо патчить.

Да, Вы абсолютно правы.

Все висит на eth0-TxRx-0, вне зависимости к какому ядру какого проца это прибито.

Кньте, плиз, ссылку на патчик (мона в личку).

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Подписчики 0
Перейти к списку тем Программное обеспечение, биллинг и *unix системы