[Стич]

64bit - желательно

хэш фильтры обязательно.

родные драйвера от intel обязательно.

А вот с HT у меня включен, но я определил какие HT для каких физических ядер

и распределяю прерывания от карт исключительно на те HT которые привязаны к конкретному ядру.

[nuclearcat]

pfifo limit 50000 - это в случае 1500 байт пакета - 75000000 (75 мбайт буфер)

Даже для указанных 2-х гигабит в ceil - это 300ms буферизации. Многовато.

Линейные правила в iptables - плохо

gro/gso - отключать, иначе шейперы не будут правильной шейпить

[vinnipux]

Спасибо за советы, на днях попробую 64-х битку с учетом ваших рекомендаций. Результат отпишу.

[photon]

Спасибо за советы, на днях попробую 64-х битку с учетом ваших рекомендаций. Результат отпишу.

64-битная система или нет -- для шейпинга и маршрутизации не важно. Все равно там сравниваются IPv4-адреса (т.е. 32-битные целые). Вот для вычислительных кластеров, где основную массу составляют операции над double-precision floats, разница довольно ощутима.

[nuclearcat]

photon, вообще-то имеет. Софт собирается сразу с поддержкой SSE/SSE2, больше регистров, сами регистры шире.

В линуксе как минимум позволяет избавиться от части локов, т.к. некоторые счетчики - 64 бит.

[Ivan_83]

Софт собирается сразу с поддержкой SSE/SSE2, больше регистров, сами регистры шире.

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

[photon]

В общем случае, ядра, которые идут в 32-битных дистрибутивах, собираются для архитектуры i686, поэтому компилятор не задействует многие инструкции, которые доступны в последних процессорах. Действительно, для ядер, собираемых под 64-битные процы, применяется больше оптимизаций. Но толку от них может быть всего несколько процентов, поскольку, как я уже говорил, ядро ОС на маршрутизаторе в основном занимается арифметикой 32-битных целых.

Изменено 12 ноября, 2012 пользователем photon

[heap]

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

[photon]

Никуда не нужно копать, просто ставьте дополнительное железо. Использование псевдоустройств приводит к созданию копий трафика в оперативной памяти, а это неоптимально.

[Lynx10]

imq сейчас вроде как не модно уже ....

ifb юзайте

 

2photon

в ifb всё тоже так печально ?

[heap]

Никуда не нужно копать, просто ставьте дополнительное железо. Использование псевдоустройств приводит к созданию копий трафика в оперативной памяти, а это неоптимально.

 

Интересная задача. Дело в том, что я все же не понимаю точки затыка - имеем 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Мбит трафика и мой тестовый траф проезжает по нему с нормальной скоростью.

Изменено 13 ноября, 2013 пользователем heap

[photon]

Можно делать shaping + policing на внутреннем интерфейсе, а на внешнем - NAT. Можно поставить для NAT отдельную машину. Кроме того, скорость может падать из-за того, что фильтры для шейпинга созданы неоптимально, без хэширования.

[vitalyb]

а кто-нибудь пробовал в такой схеме нат засунуть в отдельный namespace и пророутить через него? Не в смысле работает ли (работает), а что происодит с нагрузкой в этом случае?

[heap]

Можно делать shaping + policing на внутреннем интерфейсе, а на внешнем - NAT. Можно поставить для NAT отдельную машину. Кроме того, скорость может падать из-за того, что фильтры для шейпинга созданы неоптимально, без хэширования.

 

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

[taf_321]

Попробуйте для начала уйти с imq на ifb. По-идее, должно полегчать.

[heap]

Попробуйте для начала уйти с imq на ifb. По-идее, должно полегчать.

 

Пока не могу придумать как решить задачу, что часть трафика должна ограничится по скорости, а часть нет. Иными словами если абонент едет на определенный список префиксов - пропустить без ограничений, а если нет - обжать. Для этого, собственно, изначально и был взят 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Мбит.

Изменено 13 ноября, 2013 пользователем heap

[photon]

Есть вероятность, что у imq забивается TX queue. Его нужно увеличить.

[heap]

Есть вероятность, что у imq забивается TX queue. Его нужно увеличить.

 

Поставил 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)?

Изменено 13 ноября, 2013 пользователем heap

[kayot]

С imq я еще несколько лет назад боролся, решения так и не нашел. Начиная с какого-то потока трафика начинаются затыки, при некритичной загрузке CPU. Вероятно виноваты процедуры многократного копирования трафика в память/обратно..

Помог переход на ifb.

[heap]

С imq я еще несколько лет назад боролся, решения так и не нашел. Начиная с какого-то потока трафика начинаются затыки, при некритичной загрузке CPU. Вероятно виноваты процедуры многократного копирования трафика в память/обратно..

Помог переход на ifb.

 

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

[photon]

PS: Посмотрел другой тазик с core i7-2600. Там трафика не меньше, однако на imq проблемы нет. А вот на другом Xeon E5-54xx судя по всему ситуация схожая. Может ли связка imq+htb+железо создавать такую проблему?

PPS: Есть мысли как уйти от imq при этом сохранив возможность не шейпить определенное направление (направление некоего IX)?

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

[heap]

PS: Посмотрел другой тазик с core i7-2600. Там трафика не меньше, однако на imq проблемы нет. А вот на другом Xeon E5-54xx судя по всему ситуация схожая. Может ли связка imq+htb+железо создавать такую проблему?

PPS: Есть мысли как уйти от imq при этом сохранив возможность не шейпить определенное направление (направление некоего IX)?

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

 

Годится для реальных айпи. Есть ряд серых подсетей. Не хотелось бы городить огород типа на одном тазу шейп, на другом нат. И еще - не совсем понял про вариант с ip.

Изменено 13 ноября, 2013 пользователем heap

[photon]

Годится для реальных айпи. Есть ряд серых подсетей. Не хотелось бы городить огород типа на одном тазу шейп, на другом нат. И еще - не совсем понял про вариант с ip.

http://tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html

"огород типа на одном тазу шейп, на другом нат" - это не огород, а распределение нагрузки и упрощение правил. Плохо, когда все на одной машине крутится, и не понятно, из-за чего именно проблема.

[heap]

Сделал ifb и tc ematch ipset. Что примечательно - заворачиваем трафик на сервер и одно процессорное ядро встает в полку с ksoftirqd/7 под 100% процессора.

perf top в топе с хорошим отрывом raw spin lock.

 

rps_cpu для bond1/ifb0 раскладывают нагрузку по ядрам - но как-то многовато ее.

Изменено 13 ноября, 2013 пользователем heap

[photon]

Значит, в коде ifb до сих пор проблемы с блокировками, и его код не может выполняться одновременно на нескольких процессорах.