heap

может быть это? Не, это находил, старенький топик. Был посвежее и цифры посолиднее. Автор еще на мыло рассылал самописный модуль.

Маленький оффтоп. Где-то здесь на форуме пробегала тема, где народ роутил линуксом 10-20-30...100500Гбит с какими-то самописными модулечками для форвардинга - не могу найти. Кто-то может ткнуть носом? Или ее снесли?

Стоят такие в нескольких местах по два порта в bonding: 03:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) У них меньше ring buffer для tx: # ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX: 4080 RX Mini: 0 RX Jumbo: 16320 TX: 255 Current hardware settings: RX: 1020 RX Mini: 0 RX Jumbo: 0 TX: 255 по сравнению с Intel 82576: # ethtool -g eth2 Ring parameters for eth2: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Других принципиальных отличий не увидел. Работают себе и есть не просят.

Вопрос в небольшой оффтоп. Если мы лимитируем скорость на входе интерфейса через police rate - какой выбирать бурст? В случае с Cisco предлагалась формула: Normal burst (bytes) = CommitedAccessRate(bits) * (1/8) * 1.5 Extended burst (bytes) = 2 * Normal burst Далее проведенный эксперимент. Ставим скорость 100Мбит, а бурст 500k. Запускаем iperf. Видим что-то около 100Мбит (96 емнип) и почти стабильно. В какой-то момент вдруг она может провалится до 30-40мбит и как правило сама прийти в чувство не может (видимо tcp с окном не определяется). Если тут же перезапустить iperf - скорость снова в норме. Еще вариант - передать iperf ключик гнать 4 параллельных потока - тогда тоже суммарно едет нормально. Берем рекомендации Cisco по Normal burst и получаем для 100Мбит где-то 18750Kb бурста. Ставим эту величину. Запускаем iperf в один поток. Скорость, которую кажет iperf пляшет в некотором небольшом диапазоне (92-114Мбит), но на интерфейсе по ethstats видим честные >=100Мбит. Внимание вопрос: кто какие значения подставляет в burst для police rate?

В целом, если я правильно понимаю, корректное разложение прерываний по ядрам, добавление по необходимости rps и т.д. в итоге при наличии ресурсов процессора и полосы по интерфейсам и шине до полного их исчерпания не должно вызывать проблем в разрезе qdisc_tx_lock и не стоит периодически проверять есть ли в ЧНН реальная пропускная способность или она отсутствует. Верно ли это?

разграничивает доступ к общему ресурсу когда его хотят получить несколько CPU одновременно Ну столь общую формулировку я разгадал по слову lock. Интересно, что именно в данном контексте и кто именно делят.

А если он, то куда копать? Вопрос интересный. Мне вот тоже интересно что делает _raw_spin_lock. Мощный сервер, трафика гулькин нос как для него (загрузка CPU не превышает 1-3%), imq/ifb выброшены на свалку истории, траф к абонам htb, траф от них же police rate. В perf top пусть и с незначительным отрывом, а иногда с провалом на вторую позицию находится этот _raw_spin_lock. Рядом с ним трется ipset'овский hash_net4_test.

Можно поподробнее про вымывание кешей? Если я правильно понял - имеем, к примеру, 4 ядра и одно прерываение (один интерфейс). Прибиваем прерывание к к первому ядру, а rps ставим в f. Где будет узкое место? И какие подводные камни?

Как по моим ощущениям - совсем не ощутимо.

Я немного переделал вообще скрипт. Убрал совсем корневой класс (в конце концов мне скорость не шарить с соседними классами), повесил qdisc на дефолтный класс, перетащил матчинг ipset, влияющий на шейпера, прямо в tc. Едет вроде бы нормально. Спасибо за рекомендации. В примере кода вижу заданный для дефолтного класса quantum. Есть ли смысл его задавать явно (конечно, он ругается в dmesg, но последствий пока не наблюдал)?

Можно немного поподробнее где и чего не хватает? Если я не ошибаюсь в логике - в htb указан default 15 и есть класс 1:15 с огромной полосой. Куда нужно довесить pfifo? Судя по всему разобрался. Спасибо за совет. Парадокс ситуации в том, что ранее я не создавал даже класс 1:15, указанный как default в htb и трафик IXа отправлял во flowid 1:1, а на 1:1 не вешал никакой qdisc. И все как это ни странно работало. А тут вдруг подкрался сюрприз. Вопрос по теме - для абонентских классов всегда добавлял qdisc sfq. Нужна ли qdisc для корневого класса: class add dev bond1 parent 1: classid 1:1 htb rate 10000Mbit ceil 10000Mbit ?

Интересно - проблема с обжимкой IX в сторону абонента возникает на 3.12.0 и 3.10.19 (ну и видимо прилежащих), а на 3.2.31 и 3.0.38 проблемы не замечено.

bond1 - внутренний интерфейс. qdisc add dev bond1 ingress filter add dev bond1 parent ffff: protocol ip basic match not ipset(uaix dst) action mirred egress redirect dev ifb0 Трафик попадает на ifb еще как есть, там шейпится и уже почти в самом конце пути трансляция адресов. Обнаружил чудесный момент. Трафик точки обмена, который у меня идет к абонентам, в iptables маркируется меткой. Затем среди прочих правил на интерфейсе был такой фильтр: qdisc del dev bond1 root qdisc del dev bond1 ingress qdisc add dev bond1 ingress filter add dev bond1 parent ffff: protocol ip basic match not ipset(uaix dst) action mirred egress redirect dev ifb0 qdisc add dev bond1 root handle 1: htb default 15 class add dev bond1 parent 1: classid 1:1 htb rate 10000Mbit ceil 10000Mbit class add dev bond1 parent 1:1 classid 1:15 htb rate 10000Mbit ceil 10000Mbit filter add dev bond1 parent 1:0 protocol ip u32 filter add dev bond1 parent 1:0 handle 10: protocol ip u32 divisor 256 [b]filter add dev bond1 parent 1:0 protocol ip prio 3 handle 101 fw flowid 1:15[/b] ...тут пошли хеш фильтры и классы... Так вот. Я в ходе перетрубаций не обратил внимание, что убрал из iptables маркировку пакетов. В итоге вернул ее на место и что я вижу. Трафик, который идет вне маркера - идет на скорости повешенного в классе по абоненту шейпера. Трафик же, который был отмаркирован - скорость ощутимо падает вплоть до сотен килобит. Где ошибка? Смена маркера на матчинг ipset прямо в tc - ситуация аналогичная. Трафик где-то застряет. Причем пока сервер пустой и на нем только я с тестовым айпи - выглядит все как положено - что с маркером - не зажато, что без маркера - попало под шейпер. Но с появлением на сервере всего абон трафика - что с маркером - просаживается до каких-то странных величин, что без маркера - нормально идет сообразно шейпера.

Хочу понаблюдать какое-то время за нагрузкой, чтобы сопоставить нагрузку, которая была при imq и нагрузка, которая будет теперь. А метки не годятся - я выше писал - на этапе внутреннего интерфейса еще нет меток, а на наружном уже нет серых айпишников. Собственно по этой причине и появился imq, а теперь ifb.

А как ни крути - раньше у меня было в iptables типа заглянули в ipset if not и все что кроме матченого в ipset уехало в шейпер, что теперь: qdisc add dev bond1 ingress filter add dev bond1 parent ffff: protocol ip basic match not ipset(uaix dst) action mirred egress redirect dev ifb0 Но как ни странно именно первая попытка сделала ядро в полку. Возможно у вас редирект идет с физического интерфейса, а у меня с bond? Если я нигде не путаюсь - mark не годится в силу наличия NAT, так как уже на исходящем в интернет bond0 я серые адреса не различу.

Судя по всему нет. После добавления ff в rps_cpus для ifb0 - ничего принципиально не изменилось. Зато для всех очередей bond1 это принесло плоды. Судя по всему проблема на стадии редиректа с bond1 на ifb0. Еще пока наблюдаю.

Сделал ifb и tc ematch ipset. Что примечательно - заворачиваем трафик на сервер и одно процессорное ядро встает в полку с ksoftirqd/7 под 100% процессора. perf top в топе с хорошим отрывом raw spin lock. rps_cpu для bond1/ifb0 раскладывают нагрузку по ядрам - но как-то многовато ее.

Создать HTB с default class. Маркировать трафик в направлении IX с помощью ip или iptables (по ситуации), заворачивать маркированный трафик в default class. Псевдоустройство для этого не нужно. Годится для реальных айпи. Есть ряд серых подсетей. Не хотелось бы городить огород типа на одном тазу шейп, на другом нат. И еще - не совсем понял про вариант с ip.

А нет случайно мыслей как решить следующую задачку. В текущий момент я забиваю в ipset префиксы, которые не нужно шейпить и отправляю на imq все, кроме них. Как бы красиво выйти из положения при переходе на ifb? Как всунуть под шейпер все, кроме определенного?

Поставил 50000. Начал пробовать hfsc. Если htb - нормальная задержка, но просадка скорости. Если hfsc (пока не достоверно, но судя по всему так) скорость нормальная, но задержка скачет до 80-100мс и выше. Причем держится явно выше, чем без него, даже если айпишник генерирует трафика только один пинг. Еще наблюдение. Есть imq0 и imq1. В imq0 разворачиваем весь причастный трафик. В imq1 только мою тестовую подсеть, в которой активен только тестовый ip. На imq0 нет правил htb. На imq1 полный набор для всех подсетей. Тестируем скорость - скорость в норме. Накатываем все правила на imq0 (я все еще остаюсь на imq1). Снова тестируем. Скорость ощутимо ниже значения шейпера. Снимаем с imq0 правила. И все снова хорошо. Примечательно - на скорость в сторону абонентов это никак не влияет. Там на интерфейсе bond1 нарезка идет честная независимо от наличия правил на imq0/imq1. PS: Посмотрел другой тазик с core i7-2600. Там трафика не меньше, однако на imq проблемы нет. А вот на другом Xeon E5-54xx судя по всему ситуация схожая. Может ли связка imq+htb+железо создавать такую проблему? PPS: Есть мысли как уйти от imq при этом сохранив возможность не шейпить определенное направление (направление некоего IX)?

Пока не могу придумать как решить задачу, что часть трафика должна ограничится по скорости, а часть нет. Иными словами если абонент едет на определенный список префиксов - пропустить без ограничений, а если нет - обжать. Для этого, собственно, изначально и был взят imq. Что-то я видимо поторопился с выводами. Сейчас imq загружено с multiqueue и вроде бы как пока imq голое - пробегает все нормально. А вот повесив htb на него - скорость действительно далека от указанно в классе. Нужно еще перепроверить, но если грешить на htb - то на что именно? PS: imq0. Завернут единственный ip. В htb только: qdisc del dev imq0 root qdisc del dev imq0 ingress qdisc add dev imq0 root handle 1: htb default 15 class add dev imq0 parent 1: classid 1:1 htb rate 20000Mbit ceil 20000Mbit filter add dev imq0 parent 1:0 protocol ip u32 filter add dev imq0 parent 1:0 handle 10: protocol ip u32 divisor 256 filter add dev imq0 parent 1:0 protocol ip prio 3 handle 101 fw flowid 1:1 filter add dev imq0 parent 1:0 protocol ip u32 ht 801:: match ip src 0.0.0.0/0 hashkey mask 0xff000000 at 12 link 10: filter add dev imq0 parent 1:0 handle 11: protocol ip u32 divisor 256 filter add dev imq0 parent 1:0 protocol ip u32 ht 10:a: match ip src 10.0.0.0/8 hashkey mask 0x00ff0000 at 12 link 11: filter add dev imq0 parent 1:0 handle 12: protocol ip u32 divisor 256 filter add dev imq0 parent 1:0 protocol ip u32 ht 11:14: match ip src 10.20.0.0/16 hashkey mask 0x0000ff00 at 12 link 12: filter add dev imq0 parent 1:0 handle 13: protocol ip u32 divisor 256 filter add dev imq0 parent 1:0 protocol ip u32 ht 12:1: match ip src 10.20.1.0/24 hashkey mask 0x000000ff at 12 link 13: class add dev imq0 parent 1:1 classid 1:1003 htb rate 110Mbit ceil 110Mbit quantum 1514 mtu 1514 qdisc add dev imq0 parent 1:1003 handle 1003: sfq perturb 5 filter add dev imq0 parent 1:1 protocol ip prio 1 u32 ht 13:2: match ip src 10.20.1.2/32 flowid 1:1003 Скорость похожа на правду - около 100Мбит. Заворачиваем в imq остальной трафик (как видим в htb под фильтры он не попадает). Скорость на тестовом ip становится около 40-60Мбит. tc qdisc del dev imq0 root Скорость на тестовом ip - 400Мбит.

В том то и дело, что фильтры с хешированием. И речь о том, что в ЧНН я вообще снимаю htb с imq, просто поворачиваю на чистый imq трафик, а вижу 16мбит. А вот что касается полисинга - смогу ли я там применить хеш фильтры?

Интересная задача. Дело в том, что я все же не понимаю точки затыка - имеем 8 ядер Intel Xeon 54xx. Сказать что они все или какой-то один загружены в 100% и это точка затыка нельзя - процессорного времени хватает. Соль в том, что если я разворачиваю на imq только один свой тестовый ip - скорость есть - хоть с htb, хоть без него. Если же заворачиваю весь абонентский трафик - 16Мбит на тестовом адресе в пике и без вариантов. Неужели проблема не имеет решения? Что касается ifb - имеет место быть с одной стороны NAT, а с другой часть трафика НЕ жать, а значит разворачивать на IMQ (ifb?) не нужно. Я бы с удовольствием вообще отказался и от imq и ifb и применил бы чистый htb на интерфейсе - но NAT все портит. Какие могут быть варианты решения? Хоть в плоскости IMQ/IFB, хоть без них? Еще наблюдение - в ЧНН, когда трафика существенно больше, я по ethstats вижу на imq все 100-150Мбит трафика и сквозь него у меня трафик как я и писал составляет 16Мбит. Сейчас нагрузка суммарно куда ниже, однако вижу на imq 250-300Мбит трафика и мой тестовый траф проезжает по нему с нормальной скоростью.

Кто-нибудь выяснил как и с чем готовить imq? Наблюдаю такую ситуцию - входит трафик из сети и заворачивается на imq. Включаем некий тестовый хост среди кучи абонентского трафика - и видим даже при чистом imq скорость около 16Мбит. Убираем разворот трафика в imq - видим несколько сотен гигабит. Куда девается скорость в недрах imq? Куда копнуть?

Судя по всему таки баг имеет место быть. Нашел вот достаточно свежее: пруф