[Барагоз]

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

 

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

Созданы 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 August 31, 2014 by Барагоз

[Барагоз]

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

 

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

[pppoetest]

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

[Барагоз]

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

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

[pppoetest]

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

Судя по

два ядра из 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

[Барагоз]

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

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

Edited September 2, 2014 by Барагоз

[Saab95]

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

 

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

[Барагоз]

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

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

[Saab95]

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

 

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

 

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

 

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

[Барагоз]

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

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

 

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

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

[Saab95]

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

 

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

 

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

[Барагоз]

Конечно, вы туда подсеть указываете? Или конкретные адреса абонентов? Если конкретный адрес, то 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 September 3, 2014 by Барагоз

[GrandPr1de]

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

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

[Saab95]

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

 

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

[Барагоз]

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

160-180 Mbps.

[Барагоз]

Создайте адрес лист, в котором укажите все локальные 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 September 4, 2014 by Барагоз

[Saab95]

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

 

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

 

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

[Барагоз]

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

 

А вот это

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

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

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

 

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

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

[Saab95]

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

[aligor88]

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