[vasya_petrovich]

Всем привет!

 

Недавно начала проявляться проблема с высокой нагрузкой цпу. Perf сказал, что грузит native_queued_spin_lock_slowpath.

На машине крутится 32-х ядерный АМД 6282se, прерывания по картам прибиты, bonding + htb + skbprio + ifb + iptables. Трафика порядка ~1Gbp/s и около 2 000 классов.

В какую сторону копать?

Edited November 10, 2017 by vasya_petrovich
Решено

[default_vlan]

В 08.10.2017 в 10:39, vasya_petrovich сказал:

ашине крутится 32-х ядерный АМД 6282se, прерывания по картам прибиты, bonding + htb + skbprio + ifb + iptables

ОС какой?

[vasya_petrovich]

Debian Stretch, kernel 4.9

[default_vlan]

В 08.10.2017 в 10:39, vasya_petrovich сказал:

bonding + htb + skbprio + ifb + iptables

Кроме этого добра есть какая-нибудь СУБД и т.п.?

В top'е чем проц загружен?

[vasya_petrovich]

8 минут назад, default_vlan сказал:

Кроме этого добра есть какая-нибудь СУБД и т.п.?

В top'е чем проц загружен?

Нет, более ничего грузящего нет.

NAT на другой машине вынесен.

 

Когда удаляю qdisc на псевдоустройстве, то нагрузка резко падает и native_queued_spin_lock_slowpath идет вниз по нагрузке.
 

Цитата

tc qdisc del dev ifb0 root

Получается, что где-то в htb какая-то бяка.

Хотя там только классы, без фильтров.

[default_vlan]

6 минут назад, vasya_petrovich сказал:

Когда удаляю qdisc на псевдоустройстве, то нагрузка резко падает

в slow.log и dmesg что-то есть?

[vasya_petrovich]

В dmesg ничего лишнего не выкидывает.

А что за slow.log? Насколько мне известно он в мускуле юзается...

[default_vlan]

1 час назад, vasya_petrovich сказал:

Насколько мне известно он в мускуле юзается...

Точно.

Как я понял из описания проблемы с других форумов, эта проблема возникает по вине файловой системы (массово жалуются на ZFS), либо по причине проблем с самим диском.

Как вариант, в пик нагрузки попробуйте посмотреть в сторону nmon или dstat (nmon более информативен).

[vasya_petrovich]

Я не совсем понимаю, какая связь между htb и хардом?

[default_vlan]

1 час назад, vasya_petrovich сказал:

Я не совсем понимаю, какая связь между htb и хардом?

Я считаю, что данная нагрузка на проц следствие чего-то более глобального, нежели чем первопричина.

Я бы начал рассматривать от стандартного ввода/вывода: хард, память, сеть. Алгоритм такой:

- Что будет, если в пиковую нагрузку отрубить сетку?
- Как ведет себя память и жесткий диск в момент пиковой нагрузки? 

 

htb, насколько я понимаю, ничто иное как шейпирование трафика, поправьте, если не так. Насколько я помню, Iptables шейпировать трафик умеет, причем получше, чем любой другой сторонний софт.

Тот же top позволяет посмотреть насколько то или иное прерывание валит проц.

 

[vasya_petrovich]

34 минуты назад, default_vlan сказал:

Я считаю, что данная нагрузка на проц следствие чего-то более глобального, нежели чем первопричина.

Я бы начал рассматривать от стандартного ввода/вывода: хард, память, сеть. Алгоритм такой:

- Что будет, если в пиковую нагрузку отрубить сетку?
- Как ведет себя память и жесткий диск в момент пиковой нагрузки? 

 

htb, насколько я понимаю, ничто иное как шейпирование трафика, поправьте, если не так. Насколько я помню, Iptables шейпировать трафик умеет, причем получше, чем любой другой сторонний софт.

Тот же top позволяет посмотреть насколько то или иное прерывание валит проц.

 

Таблесы не умеют шейпировать трафик.

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

[kayot]

8 часов назад, vasya_petrovich сказал:

Получается, что где-то в htb какая-то бяка.

Хотя там только классы, без фильтров.

Это как так? А как трафик по классам раскидывается?

Косяк в логике шейпера, где-то линейный перебор правил начинается.

[vasya_petrovich]

22 минуты назад, kayot сказал:

Это как так? А как трафик по классам раскидывается?

Косяк в логике шейпера, где-то линейный перебор правил начинается.

Трафик классифицируется через ipset + skbprio

Edited October 10, 2017 by vasya_petrovich

[vasya_petrovich]

Есть небольшой прогресс.

Где-то тут на форуме писали, что прибивать очереди к ядрам надо к "близлежащему процу".
Перепривязал очереди, нагрузка резко упала на 15-20%.

 

Гуру, объясните взаимосвязь?

[nuclearcat]

Возможно особенности NUMA - адресация памяти соседнего проца очень дорого выходит

 

[Alex/AT]

А почему бы hfsc не использовать? 

[vasya_petrovich]

1 час назад, Alex/AT сказал:

А почему бы hfsc не использовать? 

Что-то пока нет желания )))

Я не видел положительных отзывов, по крайней мере на НАГе, и у местных спрашивал, они не знают, как будет работать с hfsc. Те кто сталкивался с локами и отписывался здесь на форуме в конечном итоге ушли на полисер, а меня полисер не устраивает.

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

Дело в том, что на сетевухах интегрированных в моём серваке стоят BCM5709 (Broadcom NetXtreme II), а там очереди совмещенные RxTx, хочу перекинуться на интеловскую карту I350, где очереди разделенные RX отдельно и TX отдельно.

Пробовал дрова компилить более свежие под bcm5709, но они на новом ядре не компилируются, и я особо не стал разбираться. Возможно есть какая-то опция в драйвере, которая делает разделенные очереди?
Возможно, что тогда локов будет меньше.

Отпишусь по результатам.

Edited October 13, 2017 by vasya_petrovich

[stalker86]

Скорее всего это аппаратная особенность чипа, что очереди совмещены

[Alex/AT]

В 13.10.2017 в 10:48, vasya_petrovich сказал:

Что-то пока нет желания )))

Я не видел положительных отзывов

По опыту (трёхлетней давности) могу сказать, что у HTB с lock contention полная задница. За последние годы оно чуть выровнялось, но не кардинально. Честно говоря, давно не глядел, но вроде бы на RCU его перевести нереально.

 

Я использовал HFSC на BRAS достаточно долго, не могу сказать об этом шейпере ничего негативного. Свою задачу выполняет, иерархию поддерживает, в конфигурации не сложнее HTB. Производительность выше, lock contention был намного ниже. Ну и типовых болезней HTB, связанных с квантованием, у HFSC нет.

И да, меняйте сетевухи таки на I350 или хотя бы на 82576. BCM5709 - это ужасный адаптер в плане производительности, несмотря на его 8 очередей. Хуже наверное только одноочередные 5708 и 82574... :)

[vasya_petrovich]

Переехал на Intel I350-T4.
Ситуацию особо не улучшило, по всей видимости придется пробовать с hfsc.

[kayot]

4 часа назад, Alex/AT сказал:

И да, меняйте сетевухи таки на I350 или хотя бы на 82576. BCM5709 - это ужасный адаптер в плане производительности, несмотря на его 8 очередей. Хуже наверное только одноочередные 5708 и 82574... :)

Это неправда. Поменял на нагруженном БРАСе bmc5709 на i340 - ничего не поменялось в плане загрузки и производительности.

[Pavel.M.A]

15 часов назад, Alex/AT сказал:

По опыту (трёхлетней давности) могу сказать, что у HTB с lock contention полная задница. За последние годы оно чуть выровнялось, но не кардинально. Честно говоря, давно не глядел, но вроде бы на RCU его перевести нереально.

 

Я использовал HFSC на BRAS достаточно долго, не могу сказать об этом шейпере ничего негативного. Свою задачу выполняет, иерархию поддерживает, в конфигурации не сложнее HTB. Производительность выше, lock contention был намного ниже. Ну и типовых болезней HTB, связанных с квантованием, у HFSC нет.

И да, меняйте сетевухи таки на I350 или хотя бы на 82576. BCM5709 - это ужасный адаптер в плане производительности, несмотря на его 8 очередей. Хуже наверное только одноочередные 5708 и 82574... :)

Пробовал HFSC на брасе с +\- 6к правил, но увы он отрабатывает в разы хуже HTB, на HTB проц грузится в разы меньше. Возможно я просто не умею готовить HFSC, не поделитесь примером правила для class ?

Пробовал что-то типа такова:
 

tc q replace dev eth1 root handle 1: est 1sec 8sec hfsc default ffff

tc c replace dev eth1 parent 1: classid 1:ffff est 1sec 8sec hfsc sc umax 1500b dmax 150ms rate 1Gbit ul rate 1Gbit
tc q replace dev eth1 parent 1:ffff handle ffff: pfifo

tc c replace dev eth1 parent 1: classid 1:10 est 1sec 8sec hfsc sc umax 1500b dmax 10ms rate 1Mbit ul rate 1Mbit
tc q replace dev eth1 parent 1:10 handle 10: pfifo

 

Edited October 16, 2017 by Pavel.M.A

[Alex/AT]

В 16.10.2017 в 12:43, kayot сказал:

Это неправда. Поменял на нагруженном БРАСе bmc5709 на i340 - ничего не поменялось в плане загрузки и производительности.

Значит упираетесь не в прерывания, ну или за последние годы что-то в ядре доработано.

[vasya_petrovich]

Alex/AT,  просим в студию вынести приз с вашим примером скрипта hfsc

[Alex/AT]

22 часа назад, Pavel.M.A сказал:

Пробовал HFSC на брасе с +\- 6к правил, но увы он отрабатывает в разы хуже HTB, на HTB проц грузится в разы меньше. Возможно я просто не умею готовить HFSC, не поделитесь примером правила для class ?

А можно вопрос - зачем добавляете est / umax / dmax? С заданием только sc rate / ul rate ныне есть проблемы?

vasya_petrovich

Секунду, вытаскиваю из старого кода. На выходных погоняю синтетику и напишу, есть ли разница с HTB на свежих ядрах. У меня в конфигурации использовалось огромное число классов - например на входных интерфейсах класс на сессию/сервис.

Ну, для понимания, из чего дёргаю:

        $this->asg->nq->tc_enqueue('class', 'replace', $session->params['alloc']['ingress']['dev'],
            'parent 1: classid 1:'.dechex($session->params['alloc']['ingress']['bcc']).' hfsc',
            isset($session->params['in_rate']) ?
             ('sc rate '.$session->params['in_rate'].' ul rate '.$session->params['in_rate']) :
             'sc rate 10gbit');
        $this->asg->nq->tc_enqueue('class', 'replace', $session->params['alloc']['egress']['dev'],
            ' parent 1: classid 1:'.dechex($session->params['alloc']['egress']['bcc']).' hfsc',
            isset($session->params['out_rate']) ?
             ('sc rate '.$session->params['out_rate'].' ul rate '.$session->params['out_rate']) :
             'sc rate 10gbit');