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

Mikrotik queues доки вкурил, вопросы по практике и деталям

Здравствуйте.

 

Для начала такой вопрос.

Созданы pcq типы следующего вида

name="pcq-in-8m" kind=pcq pcq-rate=8M pcq-limit=200 
    pcq-classifier=dst-address pcq-total-limit=8000 pcq-burst-rate=0 
    pcq-burst-threshold=0 pcq-burst-time=10s pcq-src-address-mask=32 
    pcq-dst-address-mask=32 pcq-src-address6-mask=128 
    pcq-dst-address6-mask=128 

name="pcq-out-5m" kind=pcq pcq-rate=5M pcq-limit=30 
    pcq-classifier=src-address pcq-total-limit=8000 pcq-burst-rate=0 
    pcq-burst-threshold=0 pcq-burst-time=10s pcq-src-address-mask=32 
    pcq-dst-address-mask=32 pcq-src-address6-mask=128 
    pcq-dst-address6-mask=128 

и аналогичные.

 

На их основе созданы простые очереди следующего вида:

name="name1" target-addresses=х.х.х.х/хх 
     interface=all parent=none packet-marks="" direction=both priority=8 
     queue=pcq-out-5m/pcq-in-8m limit-at=32k/32k max-limit=35M/70M 
     burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s 
     total-queue=default-small 

и аналогичные еще для нескольких тарифов (всего 8шт), а также есть простые очереди для юрлиц следующего вида:

name="2048-client1" target-addresses=x.x.x.x/xx interface=all 
     parent=none packet-marks="" direction=both priority=8 
     queue=default-small/default-small limit-at=0/0 max-limit=2M/2M 
     burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s 
     total-queue=default-small 

В общей сложности около 50 простых очередей.

 

При вечерней нагрузке, начиная с ~20kpps наблюдаются следующие явления:

 

- пинг на любые интерфейсы маршрутизатора растет до 20-40 мс. Это пинг из родных подсетей, с соседнего порта коммутатора, в т. ч. с адресов/на адреса, которые в очередях никак не фигурируют вообще.

- соответственно до 40-60мс растет задержка для пакетов, проходящих через маршрутизатор. Для любых, в т. ч. с адресов/на адреса, которые в очередях никак не фигурируют вообще.

- очень большая вариация задержки, от 2 до 60мс.

- если тестировать скорость на клиентах в несколько потоков, ограничения скорости pcq работают корректно.

- но при этом общие max-limitы тарифов не достигаются, то есть очевидно, из-за больших задержек клиенты не могут прокачать свое тарифное ограничение в один поток (и есть об этом жалобы).

- если при этом взять и отключить разом все очереди, то пинг моментально нормализуется (<1мс задержки через маршрутизатор), а трафик на аплинках скачкообразно увеличивается в 1,5-2 раза (то есть в ограничения аплинков при включенных очередях мы не упираемся).

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

 

При ночной/утренней/дневной нагрузке (10-15 kpps) ничего похожего не наблюдается.

Что пытался делать: перечитал pdf-ку Qos Megis, уменьшил pcq-limit=200 до 30 во всех pcq, в default-small тоже 30, в ethernet-default поставил queue size 200. Стало лучше - пинг до интерфейсов 2-12мс, через маршрутизатор задержка, соответственно, 4-25мс. Но по-прежнему плохо и по-прежнему большая вариация. Совсем до нуля уменьшать очереди не вижу смысла, т. к., как я понимаю, будет больше дропов.

 

Собственно, вопрос: что виновато и как нормализовать задержку?

 

PS Это PC, по загрузке CPU и памяти далеко до полок, сетевушки intel 82571 (PCI-E)

Edited by Барагоз

Share this post


Link to post
Share on other sites

Отследил корень проблемы, ложится вечером в 96-98% два ядра из 8 (особенно одно), которые, судя по профайлу, и занимаются главным образом queueingом. При этом остальные ядра - 5-10%. Грустьпечаль...

 

Тогда вопрос в следующем: МТ в принципе не может распределять равномерно нагрузку по ядрам на РС?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

В обычном линуксе достаточно прерывания сетевух раскидать по ядрам

У меня ощущение, что уже так и есть. Два интерфейса - два ядра напрягаются. Правда, HT включен, планирую ближайшей ночью отключить.

Share this post


Link to post
Share on other sites

У меня ощущение, что уже так и есть. Два интерфейса - два ядра напрягаются.

Судя по

два ядра из 8 (особенно одно),

это не так, вот картина жесткого привязывания сетевух.

              Device (IRQ)      CPU0     CPU1     CPU2     CPU3    TOTAL
               eth2 ( 41):        0        0       34        0       34
               eth1 ( 43):        0        0        0        0        0
        eth1-TxRx-0 ( 44):     6817        0        0        0     6817
        eth1-TxRx-1 ( 45):        0     6523        0        0     6523
        eth1-TxRx-2 ( 46):        0        0     6561        0     6561
        eth1-TxRx-3 ( 47):        0        0        0     6912     6912
               eth0 ( 48):        0        0        0        0        0
        eth0-TxRx-0 ( 49):        1        0        0        0        1
        eth0-TxRx-1 ( 50):        0        1        0        0        1
        eth0-TxRx-2 ( 51):        0        0        1        0        1
        eth0-TxRx-3 ( 52):        0        0        0        1        1
               eth3 ( 53):        0        0        0        0        0
        eth3-TxRx-0 ( 54):     6257        0        0        0     6257
        eth3-TxRx-1 ( 55):        0     6237        0        0     6237
        eth3-TxRx-2 ( 56):        0        0     6200        0     6200
        eth3-TxRx-3 ( 57):        0        0        0     5872     5872
               eth4 ( 58):        0        0        0        0        0
        eth4-TxRx-0 ( 59):      771        0        0        0      771
        eth4-TxRx-1 ( 60):        0     1916        0        0     1916
        eth4-TxRx-2 ( 61):        0        0      533        0      533
        eth4-TxRx-3 ( 62):        0        0        0     1659     1659

Share this post


Link to post
Share on other sites

В МТ вижу только одно прерывание на каждую сетевуху. Отключил HyperThreading, назначил прерывания сетевух на наименее загруженные ядра. Сейчас ниболее загруженные ядра - 50-60%, иногда всплески до 75%. На пинг радикально не повлияло. Так же до интерфейсов чуть лучше, 1-8мс, на проход 2-25мс, так же недобираются max-limitы.

Призываются гуру микротика)

Edited by Барагоз

Share this post


Link to post
Share on other sites

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

 

Кроме всего не нужно уменьшать буфер пакетов, обычно для простых очередей ставят 200-500 пакетов, а на PCQ - 100000 пакетов с лимитом в 2000-5000.

Share this post


Link to post
Share on other sites

Машина, о которой идет речь - pptp концентратор, через него в принципе не ходят пакеты, 'передающиеся внутри сети'.

Насчет очередей фраза в корне противоречит теории (изложенной, например, в Qos Megis), длинная очередь увеличивает задержку, а никак не уменьшает. Что подтверждается моим опытом)

Share this post


Link to post
Share on other sites

Машина, о которой идет речь - pptp концентратор, через него в принципе не ходят пакеты, 'передающиеся внутри сети'.

 

А как же они ходят? У вас же не PPPoE, следовательно сначала до него дойдут по IP данные, упакованные в туннель, а потом данные из туннелей пройдут по маршрутизатору через цепочку правил, следовательно вам нужно исключить попадание адресов транспортной сети под ограничения.

 

Насчет очередей фраза в корне противоречит теории (изложенной, например, в Qos Megis), длинная очередь увеличивает задержку, а никак не уменьшает. Что подтверждается моим опытом)

 

Так проведите тесты - если очередь большая, то когда под ограничение не попадает, то и задержки никакой нет, если абонент потребляет с такой скоростью, что данные сохраняются в буфере, начинает увеличиваться задержка, что сообщает приложениям о необходимости снизить скорость (собственно так и происходит), в итоге график потребления по абоненту оказывается не прямой линией, а волнами. При этом если нет дропов, то и нет потерь входящей полосы, т.к. данные до вашего сервера уже пришли, и нет смысла их дропать, т.к. абонент закажет переповтор. Соответственно правильно настроив размер пакета, можно освободить 10-15 процентов от входящего канала, который на переповторы расходуется.

Share this post


Link to post
Share on other sites

вам нужно исключить попадание адресов транспортной сети под ограничения.

Поля target address недостаточно? Поясните.

 

Так проведите тесты

Провели. Увеличение длины очереди увеличивает пинг.

Share this post


Link to post
Share on other sites

Поля target address недостаточно? Поясните.

 

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

 

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

Share this post


Link to post
Share on other sites

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

См. первое сообщение темы. В этом плане всё правильно. Где simple queue с типом PCQ - там подсеть для тарифа. Где simple queue типа default-small - там индивидуальный IP.

 

Окей.

Абстрагируемся от простых очередей. Невелика задача. Только что перевел все мощные PCQшные очереди в дерево. Пинг мистическим образом стал близок к норме (1-4 мс на проход) при той же пакетной нагрузке.

Вопрос теперь в другом появился.

Выбираем любой тариф, смотрим статистику мэнгла для тарифа в направлении к абонентам - видим общую полосу, потребляемую юзерами этого тарифа. Похожую на правду.

Смотрим статистику очереди этого тарифа (Avg rate) - видим полосу ровно в два раза больше, чем в мэнгле :)

 

Вот мэнгл:

chain=forward action=mark-packet new-packet-mark=markname passthrough=no 
    dst-address-list=tarifname 

 

Вот очередь:

name="tarifname" parent=global-vpn-download packet-mark=markname limit-at=30M 
    queue=pcq-in-2m priority=5 max-limit=50M burst-limit=0 burst-threshold=0 
    burst-time=0s 

 

Вот ее parent

name="global-vpn-download" parent=global-out packet-mark="" limit-at=0 
    priority=8 max-limit=400M burst-limit=0 burst-threshold=0 burst-time=0s

 

Повесил на global-out, т. к. считаем впн-клиентов и в соответствующих адрес-листах фигурируют адреса 'внутритуннельные'.

Что на этот раз я делаю не так?)

 

Скорость клиентам режет правильно. Врет в два раза именно в общей полосе.

Пока что просто удвоил limit-at и max-limit для каждого тарифа, чтобы фактические полоски были аналогичны тем, которые нарезались простыми очередями. Но как-то это ненаглядно и вообще неправильно, раз уж переехал на дерево, хочу его более тонко построить и отслеживать, а тут получается 4 пишем, 2 в уме.

Edited by Барагоз

Share this post


Link to post
Share on other sites

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

20кппс - в вашем случае в мегабитах сколько?

Share this post


Link to post
Share on other sites

Маркируете не правильно. Нужно по двум направлениям.

 

Создайте адрес лист, в котором укажите все локальные IP адреса, в первом правиле маркируйте все пакеты, где src.address-list, то есть исходящий трафик от абонентов, его в отдельную ветку исходящего, второй по dst.address-list, то есть входящий трафик к абонентам, его так же в отдельную ветку входящего.

Share this post


Link to post
Share on other sites

Создайте адрес лист, в котором укажите все локальные IP адреса, в первом правиле маркируйте все пакеты, где src.address-list, то есть исходящий трафик от абонентов, его в отдельную ветку исходящего

Так и есть.

Вот мэнгл:

chain=forward action=mark-packet new-packet-mark=vpn-upload passthrough=no 
    src-address=10.0.5.65-10.0.7.255

Вот его очередь:

name="vpn-upload-5m" parent=global-vpn-upload packet-mark=vpn-upload 
    limit-at=45M queue=default-small priority=8 max-limit=90M burst-limit=0 
    burst-threshold=0 burst-time=0s 

То есть всем впн-клиентам я дал одну и ту же полосу аплоада, независимо от тарифа. И тут, кстати, всё правильно считается, Avg. rate совпадает со статистикой мэнгла)

 

второй по dst.address-list, то есть входящий трафик к абонентам, его так же в отдельную ветку входящего

А это уже непонятно, как тогда исходящий по тарифам разбирать, если все будут в одном адрес-листе?

Edited by Барагоз

Share this post


Link to post
Share on other sites

А это уже непонятно, как тогда исходящий по тарифам разбирать, если все будут в одном адрес-листе?

 

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

 

Хотя лучше всего делать не так - поставить терминатор, который либо вообще не будет ограничивать скорость абонентам, либо будет ограничивать ее простыми правилами, далее ставите основной шейпер, на котором уже разбираете абонентов в сторону интернета по разным правилам, а после него уже NAT или пограничный шлюз, если адреса белые. Тогда будет самая высокая производительность.

Share this post


Link to post
Share on other sites

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

 

А вот это

chain=forward action=mark-packet new-packet-mark=markname passthrough=no 
    dst-address-list=tarifname 

чем не оно? Таких правил 8шт, соответствуют разным тарифам. В мэнгле всё ОК, в очереди общую полосу врет в два раза. См. сообщение №12.

Если что-то в деталях делаю не так, поясните...

 

Хотя лучше всего делать не так - поставить терминатор, который либо вообще не будет ограничивать скорость абонентам, либо будет ограничивать ее простыми правилами, далее ставите основной шейпер, на котором уже разбираете абонентов в сторону интернета по разным правилам, а после него уже NAT или пограничный шлюз, если адреса белые. Тогда будет самая высокая производительность.

Логично. Но рано. Будет нагрузка хотя бы в 500 Мбит/с входящего - будем городить огород.

Share this post


Link to post
Share on other sites

У вас роутер является шлюзом от лица которого пакеты отправляются абонентам? Поиграйтесь не с forward а с input и output, ведь когда роутер работает натом, то клиентам отправляет данные от своего имени, то есть с output.

Share this post


Link to post
Share on other sites

барагоз, ты разобрался с проблемам, хотелось бы услышать концовку

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