[Ilya Evseev]

Имеется генератор правил масс-шейпинга для tc+htb:

http://sources.homelink.ru/shaping/tc-shaper.txt

 

На выходе у него примерно такая простыня:

http://sources.homelink.ru/shaping/tc-shaper-data0.txt

 

Для генерации фильтров используется утилита prefixtree:

http://vcalinus.gemenii.ro/?p=9

 

При низких нагрузках работает нормально.

При высоких (>5-6к клиентов, >3gbps) на сервере растёт LA до 1 и более,

ответы на пинг через LAN-интерфейс приходят с задержкой в несколько секунд,

скорость форвардинга через LAN-интерфейс проседает на порядок (на остальных интерфейсах нормально).

 

Отключаю шейпер - всё становится замечательно, пинги быстрые, LA низкий, форвардинг без тормозов.

 

Началось после обновления ядра с 2.6.32 до 3.2.0 (amd64).

 

На что было обращено внимание:

1) ethtool -k/-K -- всё установлено в off

2) На листья повешен sfq

3) Добавлен default class для htb в qdisc -- http://forum.nag.ru/forum/index.php?showtopic=70693

4) iproute обновлён -- http://forum.nag.ru/forum/index.php?showtopic=79051&view=findpost&p=756689

 

Ссылки на полный список правил для "tc -b" и вывод "tc -s" готов прислать через ЛС, т.к. там фактические данные клиентов.

[NiTr0]

При высоких (>5-6к клиентов, >3gbps) на сервере растёт LA до 1 и более

ksoftirqd кушает небось много?

Что профайлинг говорит? Как нагрузка по ядрам распределена? Что за сетевуха (10ка или бондинг из гиговых)?

[Ilya Evseev]

Как нагрузка по ядрам распределена?

Через smp_affinity. По 40-80%.

 

Что за сетевуха (10ка или бондинг из гиговых)?

Бондинг из нескольких e1000e и igb. Драйверы igb свежие, с ITR.

[photon]

Что будет, если на листья повесить pfifo вместо sfq?

[Ilya Evseev]

Что будет, если на листья повесить pfifo вместо sfq?

То же самое. Первоначально ничего не вешалось, т.е. была pfifo.

[Ilya Evseev]

ksoftirqd кушает небось много?

Не очень. Вот сейчас LA и задержка пингов постепенно начинают подрастать:

 

 1  [                                                          0.0%]     Tasks: 111 total, 2 running
 2  [||||||||||||||||||||||||||||||||||||||                   60.8%]     Load average: 0.13 0.30 0.34 
 3  [|||||||||||||||||||||                                    32.7%]     Uptime: 7 days, 10:10:57
 4  [|||||||||||||||||||||||                                  36.7%]     Time: 17:24:14
 5  [|||||||||||||||||||||||||||||||||||||||||                64.9%]     Mem:7997M used:1323M buffers:132M cache:6389M 
 6  [||||||||||||||||||||||||||||||||||||||                   61.0%]
 Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||1323/7997MB]
 Swp[                                                         0/0MB]

 PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
  23 root      20   0     0     0     0 S  9.0  0.0  3h47:10 ksoftirqd/4
  27 root      20   0     0     0     0 S 10.0  0.0  4h21:21 ksoftirqd/5
  10 root      20   0     0     0     0 S  8.0  0.0  4h42:34 ksoftirqd/1
  15 root      20   0     0     0     0 R  3.0  0.0  1h03:42 ksoftirqd/2
  19 root      20   0     0     0     0 S  2.0  0.0 48:28.70 ksoftirqd/3
 288 root      20   0     0     0     0 S  1.0  0.0  1h40:17 kworker/4:1
 289 root      20   0     0     0     0 S  0.0  0.0 44:51.92 kworker/5:1
 294 root      20   0     0     0     0 S  0.0  0.0 49:57.44 kworker/1:1
1743 root      20   0  117M  1424  1064 S  0.0  0.0  0:35.53 /usr/sbin/rsyslogd -c4
18266 root      20   0 19644  1564  1112 R  2.0  0.0  0:00.70 htop
1886 quagga    20   0  387M  356M   936 S  0.0  4.5  3h43:13 /usr/lib/quagga/bgpd --daemon -A 127.0.0.1
  28 root      RT   0     0     0     0 S  0.0  0.0  0:09.92 watchdog/5
 291 root      20   0     0     0     0 S  0.0  0.0 16:28.73 kworker/2:1
  16 root      RT   0     0     0     0 S  0.0  0.0  0:03.28 watchdog/2
  20 root      RT   0     0     0     0 S  0.0  0.0  0:02.81 watchdog/3

[NiTr0]

Наблюдал подобное на 2.6.35.* при шейпере поверх бондинга. Правда, при несколько меньшем траффике, и при простом шейпере (приоритезация трафла для сглаживания полки). Без бондинга подобный шейпер на другом бордюре работал прекрасно. На более свежих ядрах не тестировал.

[Ilya Evseev]

Наблюдал подобное на 2.6.35.* при шейпере поверх бондинга. Правда, при несколько меньшем траффике, и при простом шейпере (приоритезация трафла для сглаживания полки). Без бондинга подобный шейпер на другом бордюре работал прекрасно.

Оно?

http://marc.info/?t=124022656800008&r=1&w=2

[Ilya Evseev]

Попробовал заменить HTB на HFSC:

htb rate ... ceil ...

на

hfsc sc rate ... ul rate ...

 

Получившийся список правил:

http://sources.homelink.ru/shaping/tc-shaper-data1.txt

 

Результат:

Система сразу же после начала загрузки правил встала колом, загрузка трех ядер по 90%,

в топе три ksoftirqd и следом за ними три kworker на этих же ядрах.

Подтормаживать стала даже локальная консоль.

Вылечилось немедленным tc qdisc del dev vlan120/ifb0 root/ingress

 

Это правила HFSC составлены мною неверно, или дело в чём-то другом?

[s.lobanov]

Отключаю шейпер - всё становится замечательно, пинги быстрые, LA низкий, форвардинг без тормозов.

 

Отключаете в каком направлении? Если заменить US(от абонента к серверу) shaping на police, то такие же проблемы?

[Ilya Evseev]

Отключаете в каком направлении?

Сначала пробовал только "tc qdisc del dev ifb0 root" -- становилось заметно легче, но не полностью.

Например, _входящий_ (к клиенту) файл начинал скачиваться быстро.

 

Нормально становится только при отключении в обоих направлениях.

 

Если заменить US(от абонента к серверу) shaping на police

Это как? Можете написать конкретный синтаксис?

[photon]

Это как? Можете написать конкретный синтаксис?

В скрипте sc это один из режимов. В конфиге нужно указать limit_method = policing, а правила выводятся на экран командой sc -d 2 load.

[NiTr0]

Оно?

Может и оно, не помню уже. Помню что скорость в один поток сильно падала, и вроде дропы тоже были.

К слову, почему выбрано 3.2.0 ядро? Из каких соображений?

[Ilya Evseev]

почему выбрано 3.2.0 ядро? Из каких соображений?

Из Debian backports. Точная версия - 3.2.23-1~bpo60+2

[s.lobanov]

Если заменить US(от абонента к серверу) shaping на police

Это как? Можете написать конкретный синтаксис?

 

tc filter add dev $DEVICE parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${UPSPEED}kbit burst ${UPBURST}k drop flowid :1

 

Преимущество - ресурсоэкономия(cpu,memory). Недостаток - upstream для tcp-потока будет не очень гладким, но 99.9% это даже не заметят(в отличии от DS). И второй недостаток - нет справедливого(или подобного) разделения канала, т.е. если за CPE с одного PC будет работать torrent на раздачу на полную катушку, то с другого будет тяжело выгрузить фоточки вконтактик.

[Петрович-2012]

а если 5000 правил полисинга? с хэшфильтрами оно точно быстро работает

[NiTr0]

Из Debian backports. Точная версия - 3.2.23-1~bpo60+2

Точную версию бы предпочтительно указывать. А то выглядит, как использование ванильного ядра полугодичной давности без багфиксов.

Если так - то печально, пинать тогда ядреных разработчиков через багзиллу и через мэйллисты.

 

а если 5000 правил полисинга?

пофиг, 1 правило на ифейс. Но на спидтесте, так любимом хомяками, с апстримом будет все очень печально, и в сети самозародится выводок хомяков, уверенных, что им провайдер недоливает инета за который они уплатили.

[Петрович-2012]

проясните пожалуйста фразу "1 правило на ифейс". У топик стартера ">5-6к клиентов" а интерфейс один, на нем будет 5-6к правил? Хочу понять как полисинг будет вести себя на больших нагрузках

Edited October 18, 2012 by Петрович-2012

[Петрович-2012]

однозначно свежее ядро нужно ставить, у меня на 3.2.1 точно такие же грабли были

[NiTr0]

а интерфейс один

vlan per user у него, судя по предоставленым правилам.

 

у меня на 3.2.1 точно такие же грабли были

А на каком ядре они не наблюдаются?

[Петрович-2012]

3.4.9 например

покажите perf top