voron Опубликовано 16 июля, 2015 (изменено) · Жалоба Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet? for ETH in eth0 do tc qdisc del dev $ETH root 2>/dev/null tc qdisc add dev $ETH root handle 100: mq for i in `seq 1 4` do tc qdisc add dev $ETH parent 100:$i handle $i htb default 1 done done как минимум нужно добавить фильтр(ы) на корневой mq для привязки трафика клиентов к очередям, иначе трафик одного клиента может шейпиться во всех очередях с суммированием скорости. Изменено 16 июля, 2015 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 30 июля, 2015 · Жалоба Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet? for ETH in eth0 do tc qdisc del dev $ETH root 2>/dev/null tc qdisc add dev $ETH root handle 100: mq for i in `seq 1 4` do tc qdisc add dev $ETH parent 100:$i handle $i htb default 1 done done как минимум нужно добавить фильтр(ы) на корневой mq для привязки трафика клиентов к очередям, иначе трафик одного клиента может шейпиться во всех очередях с суммированием скорости. Господа, поделюсь свежими новостями. Дисциплина mq действительно творит чудеса! Все становится просто великолепно, но есть одно НО... :) В предложенном диалоге с Эриком Думазетом человек использует дисциплину multiq и с ней же использует skbedit queue_mapping. Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 30 июля, 2015 · Жалоба IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько. Копать надо не в сторону распределения, а в сторону - почему загрузка растет. Еще более IMHO - где-то в конфиге шейпера тупо не хватает размеров очередей(qdisc), и как только у вас растет нагрузка выше пары процентов начинается беда(трафик не успевает разливаться по классам). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 30 июля, 2015 · Жалоба IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько. Копать надо не в сторону распределения, а в сторону - почему загрузка растет. Еще более IMHO - где-то в конфиге шейпера тупо не хватает размеров очередей(qdisc), и как только у вас растет нагрузка выше пары процентов начинается беда(трафик не успевает разливаться по классам). Вы не правы, HTB имеет один общий лок на всю иерархию дерева. Распределение по ядрам в данном случае просто позволяет создать отдельные инстансы деревьев на удельный объем pps. Плюс к этому загрузка у меня НЕ растет, как я отмечал в последних сообщениях, просто трафик встает колом внутри бриджа. Плюс mq решил проблему - трафик больше НЕ встает колом, но возникает пикантная ситуация, когда клиент получает bandwidth*queue_num без queue_mapping. :) Собственно, в чем и вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 июля, 2015 · Жалоба По аналогии. Сделать несколько деревьев хэш-фильтров в соответствии с тем, как классы были поделены между деревьями HTB. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 30 июля, 2015 · Жалоба По аналогии. Сделать несколько деревьев хэш-фильтров в соответствии с тем, как классы были поделены между деревьями HTB. Нее... Вы меня тоже не поняли. Смотрите, сделал на mq несколько деревьев HTB и все работает ЗАМЕЧАТЕЛЬНО. Только... Если у клиента rate limit, скажем, 5мбит/с и он ставит на закачку файл - он получает свои 5 Мбит. Ставит еще один файл и получает еще 5 Мбит. И т.д. Пока не заюзает все очереди в mq. В multiq это решается, как уже сказали, skbedit queue_mapping, например по первому октету клиента отправляем в первую очередь, если .0/28, во вторую очередь, если .16/28 и т.д. То есть, клиентов жестко приколачиваем к очередям multiq. А в mq это не получается - если я делаю filter action skbedit queue_mapping с parentid root qdisc mq, то в ответ получаю Operation not supported. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба UP. Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet? for ETH in eth0 do tc qdisc del dev $ETH root 2>/dev/null tc qdisc add dev $ETH root handle 100: mq for i in `seq 1 4` do tc qdisc add dev $ETH parent 100:$i handle $i htb default 1 done done как минимум нужно добавить фильтр(ы) на корневой mq для привязки трафика клиентов к очередям, иначе трафик одного клиента может шейпиться во всех очередях с суммированием скорости. Господа, поделюсь свежими новостями. Дисциплина mq действительно творит чудеса! Все становится просто великолепно, но есть одно НО... :) В предложенном диалоге с Эриком Думазетом человек использует дисциплину multiq и с ней же использует skbedit queue_mapping. Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 31 июля, 2015 · Жалоба IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько. Копать надо не в сторону распределения, а в сторону - почему загрузка растет. +1 столкнулся в своё время, что сам накосячил. проверьте, у вас tc правильно настроен? http://www.opennet.ru/docs/RUS/LARTC/x1661.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба IMHO вы какой-то ерундой страдаете. HTB параллелится(как и любые обработчики трафика в linux), аппаратный RSS нагрузку по ядрам распределяет ровненько. Копать надо не в сторону распределения, а в сторону - почему загрузка растет. +1 столкнулся в своё время, что сам накосячил. проверьте, у вас tc правильно настроен? http://www.opennet.ru/docs/RUS/LARTC/x1661.html Ах, ну бросьте... До 2,5GBit/s все работает правильно, а потом начинаются проблемы? Хэши, конечно, есть. Гигабит у меня шейпится совершенно без нареканий, что на igb, что на ixgbe и два шейпится без проблем. :) Если вы делали шейпер на трафик >3 GBit (3-вход/3-выход GBit/s), то приветствую конструктивную критику. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 31 июля, 2015 · Жалоба Да понятно, что хэши есть. Вопрос в том, правильно ли настроены? Просто у меня в данный момент, как раз в ЧНН нагрузка 2-2.5 достигает. Вернутся отпускники и не хотелось бы словить нежданчик в отпуске, в который завтра отъезжаю. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба Да понятно, что хэши есть. Вопрос в том, правильно ли настроены? Просто у меня в данный момент, как раз в ЧНН нагрузка 2-2.5 достигает. Вернутся отпускники и не хотелось бы словить нежданчик в отпуске, в который завтра отъезжаю. :))) Я вам гарантирую приятный сюрприз. Хотя в вашем случае, возможно, будет попроще... Вы же на bonding`е собираете? Там есть выбор очередей через /sys. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 31 июля, 2015 · Жалоба Нет. Исключительно по 10G интерфейсу. Начитался на данном форуме про проблемы в бондинге. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба Нет. Исключительно по 10G интерфейсу. Начитался на данном форуме про проблемы в бондинге. Тогда можете оценить - как далеко вы от проблемы. Я использую ядро 3.18, здесь я на одном дереве HTB НЕ наблюдаю деградации пинга во время просадки шейпинга, clocksource=tsc, кол-во абонентов около 7k (загоняется в хэши), pps, при котором начинает деградировать скорость (по интерфейсу) 450kpps (вход), 400 kpps (выход). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 31 июля, 2015 · Жалоба И все же я уверен что узкое место где-то в конфигурации дерева, а не в локах и потоках. При запуске нескольких деревьев у вас через каждое меньше трафика бегает, естественно проблема устраняется. Quantum увеличили, как на прошлой странице говорили? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба И все же я уверен что узкое место где-то в конфигурации дерева Ну естественно - это причина! Иначе бы от трафика бы и не зависело. , а не в локах и потоках. А это - следствие. У вас есть дерево иерархическое, которое необходимо обходить и некоторый поток данных. А также есть таймер, пускай будет tsc (clocksource), который определяет инертность фильтров в дисциплине (HTB). Так вот в какой-то момент разрешения таймера перестает хватать на это дерево и трафик. Хотя проца еще далеко полно. При запуске нескольких деревьев у вас через каждое меньше трафика бегает, естественно проблема устраняется. Quantum увеличили, как на прошлой странице говорили? :) Можно крутить очереди, quantum и прочее, увеличивая задержки в трубках HTB, и, отчасти, наверное это где-то решит проблему, но мне то надо получить правдивый мост с минимально вносимой задержкой, который нарезает большое кол-во трубок (7k) на большой трафик (>3GB/s). Вы сами имели дело с такими шейперами или нет? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба Еще раз апну тему. Еще раз вопрос - как всеже можно увести пакет в определенную аппаратную TX очередь? Условие - при создании корневого qdisc - mq, на него нельзя присоединить фильтры, соответственно нельзя сделать skbedit queue_mapping. Как еще это можно обойти? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 31 июля, 2015 (изменено) · Жалоба Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?похоже управлять рассовыванием можно только в multiq. Вы пробовали multiq сразу вместе с пачкой фильтров с queue_mapping ? Статистика tc что показывает? Версия iproute2 соответствует версии ядра?Вот что у меня с multiq и без фильтров [root@ ~]# ./tc q d dev p4p1 root; ./tc q a dev p4p1 root handle 1: multiq [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 [root@ ~]# for i in `seq 1 16` ; do ./tc qdisc add dev p4p1 parent 1:$i handle 1${i}: htb;done [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 qdisc htb 11: parent 1:1 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 12: parent 1:2 r2q 10 default 0 direct_packets_stat 4043 direct_qlen 1000 qdisc htb 13: parent 1:3 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 14: parent 1:4 r2q 10 default 0 direct_packets_stat 170 direct_qlen 1000 qdisc htb 15: parent 1:5 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 16: parent 1:6 r2q 10 default 0 direct_packets_stat 1170 direct_qlen 1000 qdisc htb 17: parent 1:7 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 18: parent 1:8 r2q 10 default 0 direct_packets_stat 861 direct_qlen 1000 qdisc htb 19: parent 1:9 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 110: parent 1:10 r2q 10 default 0 direct_packets_stat 3414 direct_qlen 1000 qdisc htb 111: parent 1:11 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 112: parent 1:12 r2q 10 default 0 direct_packets_stat 276 direct_qlen 1000 qdisc htb 113: parent 1:13 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 114: parent 1:14 r2q 10 default 0 direct_packets_stat 1610 direct_qlen 1000 qdisc htb 115: parent 1:15 r2q 10 default 0 direct_packets_stat 1 direct_qlen 1000 qdisc htb 116: parent 1:16 r2q 10 default 0 direct_packets_stat 426 direct_qlen 1000 [root@ ~]# ./tc q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 qdisc htb 11: parent 1:1 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 12: parent 1:2 r2q 10 default 0 direct_packets_stat 5685 direct_qlen 1000 qdisc htb 13: parent 1:3 r2q 10 default 0 direct_packets_stat 3 direct_qlen 1000 qdisc htb 14: parent 1:4 r2q 10 default 0 direct_packets_stat 497 direct_qlen 1000 qdisc htb 15: parent 1:5 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 16: parent 1:6 r2q 10 default 0 direct_packets_stat 3017 direct_qlen 1000 qdisc htb 17: parent 1:7 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 18: parent 1:8 r2q 10 default 0 direct_packets_stat 1270 direct_qlen 1000 qdisc htb 19: parent 1:9 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 110: parent 1:10 r2q 10 default 0 direct_packets_stat 5136 direct_qlen 1000 qdisc htb 111: parent 1:11 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 112: parent 1:12 r2q 10 default 0 direct_packets_stat 817 direct_qlen 1000 qdisc htb 113: parent 1:13 r2q 10 default 0 direct_packets_stat 0 direct_qlen 1000 qdisc htb 114: parent 1:14 r2q 10 default 0 direct_packets_stat 4229 direct_qlen 1000 qdisc htb 115: parent 1:15 r2q 10 default 0 direct_packets_stat 1 direct_qlen 1000 qdisc htb 116: parent 1:16 r2q 10 default 0 direct_packets_stat 771 direct_qlen 1000 [root@ ~]# То есть пакеты без фильтров тоже распределяются по очередям. А у вас при распределении по очередям нагрузка не распределяется по ядрам? Изменено 31 июля, 2015 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 (изменено) · Жалоба Я попробовал использовать multiq, он не дал ожидаемого преимущества перед одним инстансом htb, как это получилось у mq. Случилось тоже самое, что и при одном дереве htb. А в mq - все OK, но с mq не работает queue_mapping :), tc пишет - Operation not permitted. Дело осталось за малым - рассовать ip строго по очередям. Но как?похоже управлять рассовыванием можно только в multiq. Вы пробовали multiq сразу вместе с пачкой фильтров с queue_mapping ? Статистика tc что показывает? Версия iproute2 соответствует версии ядра? У меня multiq не создает видимых очередей по количеству аппаратных, как это делает mq, просто вижу ./tc -s -d q s dev p4p1 qdisc multiq 1: root refcnt 65 bands 24/64 Sent 38674147 bytes 25920 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Да, пробовал, конечно. Иначе queue_mapping не сработает, если мне не изменяет память. John Fastabend из Intel, разраб mqprio подтвердил, что multiq имеет также лок и только mq и mqprio не имеют локов. Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске. Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька? Изменено 31 июля, 2015 пользователем tartila Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 31 июля, 2015 (изменено) · Жалоба Да, пробовал, конечно. Иначе queue_mapping не сработает, если мне не изменяет память. John Fastabend из Inrel, разраб mqprio подтвердил, что multiq имеет также лок и только mq и mqprio не имеют локов. тогда вся надежда на настройку аппаратного интелового flow director так чтобы трафик одного клиента попадал всегда в одну и ту же очередь. Правда flow director работает на прием, а не на передачу. Но суть его как я понимаю- отправлять с той же очереди(с того же ядра) с которой пакет получен. То есть ручные правила применяться должны и на rx и на tx. Хотя может и применяются только на rx, а tx просто берет номер очереди из "flow track". Это если одна сетевка на все про все. Изменено 31 июля, 2015 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 31 июля, 2015 · Жалоба Безумная идея возникла, а корневой класс случайно не ограничили на 2.5 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
BETEPAH Опубликовано 31 июля, 2015 · Жалоба Признаюсь, ступил, 100% загрузки при этом не должно быть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 31 июля, 2015 (изменено) · Жалоба Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске. он уходит в железо скорее всего. Та же mqprio работает с аппаратным director'ом по очередям на основе skb priority. Видимо все программные механизмы будут давать блокировку.Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька?а если iptables'ами выставлять QoS и потом mqprio ? В древней доке почему-то приведен кривой пример с фильтром на mqprio, у меня фильтр не ложится на mqprio. Изменено 31 июля, 2015 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 31 июля, 2015 · Жалоба Короче, смысл работы таков, что надо понять, как обмануть коллбэк select_queue в ixgbe/igb. То есть, там есть какой то алгоритм по выбору TX очереди - скорее всего round robin, а требуется определить ручками - например, по маске. он уходит в железо скорее всего. Та же mqprio работает с аппаратным director'ом по очередям на основе skb priority. Видимо все программные механизмы будут давать блокировку.Я видел в инете упоминания о map-queue в iptables, но у меня такого нет. Видимо, требуется обновить iptables. Кто может подтвердить - работает ли эта фигулька?а если iptables'ами выставлять QoS и потом mqprio ? В древней доке почему-то приведен кривой пример с фильтром на mqprio, у меня фильтр не ложится на mqprio. У меня mqprio не запускается :), Fastabend забил на него, а он на некоторых сетевках не стартует :)))) Поэтому я не экспериментировал с ним. А вот как выбирается TX очередь - это загадка. Буду в понедельник копать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 31 июля, 2015 (изменено) · Жалоба Т.е. ситуация такая: нужно либо убирать локи из multiq, либо добавить в mq возможность повесить фильтр с action skbedit queue_mapping. Иного выхода, как допилить самому или обращаться к разработчикам я не вижу. В той рассылке появлялся некто John Fastabend, скорее всего он за это и отвечает. Вот тут человек что-то пытается сделать с помощью ipset: http://www.spinics.net/lists/netdev/msg318787.html . Попробуйте полисеры для разнообразия, они хоть и менее качественно нарезают, но работают без глобального лока, в отличие от HTB. Изменено 31 июля, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 31 июля, 2015 · Жалоба нужно либо убирать локи из multiq, либо добавить в mq возможность повесить фильтр с action skbedit queue_mapping либо перепилить htb - идея здесь: http://www.ijcset.com/docs/IJCSET13-04-04-113.pdf (возможно, это будет проще). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...