vasya_petrovich Опубликовано 8 октября, 2017 (изменено) · Жалоба Всем привет! Недавно начала проявляться проблема с высокой нагрузкой цпу. Perf сказал, что грузит native_queued_spin_lock_slowpath. На машине крутится 32-х ядерный АМД 6282se, прерывания по картам прибиты, bonding + htb + skbprio + ifb + iptables. Трафика порядка ~1Gbp/s и около 2 000 классов. В какую сторону копать? Изменено 10 ноября, 2017 пользователем vasya_petrovich Решено Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
default_vlan Опубликовано 10 октября, 2017 · Жалоба В 08.10.2017 в 10:39, vasya_petrovich сказал: ашине крутится 32-х ядерный АМД 6282se, прерывания по картам прибиты, bonding + htb + skbprio + ifb + iptables ОС какой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 · Жалоба Debian Stretch, kernel 4.9 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
default_vlan Опубликовано 10 октября, 2017 · Жалоба В 08.10.2017 в 10:39, vasya_petrovich сказал: bonding + htb + skbprio + ifb + iptables Кроме этого добра есть какая-нибудь СУБД и т.п.? В top'е чем проц загружен? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 · Жалоба 8 минут назад, default_vlan сказал: Кроме этого добра есть какая-нибудь СУБД и т.п.? В top'е чем проц загружен? Нет, более ничего грузящего нет. NAT на другой машине вынесен. Когда удаляю qdisc на псевдоустройстве, то нагрузка резко падает и native_queued_spin_lock_slowpath идет вниз по нагрузке. Цитата tc qdisc del dev ifb0 root Получается, что где-то в htb какая-то бяка. Хотя там только классы, без фильтров. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
default_vlan Опубликовано 10 октября, 2017 · Жалоба 6 минут назад, vasya_petrovich сказал: Когда удаляю qdisc на псевдоустройстве, то нагрузка резко падает в slow.log и dmesg что-то есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 · Жалоба В dmesg ничего лишнего не выкидывает. А что за slow.log? Насколько мне известно он в мускуле юзается... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
default_vlan Опубликовано 10 октября, 2017 · Жалоба 1 час назад, vasya_petrovich сказал: Насколько мне известно он в мускуле юзается... Точно. Как я понял из описания проблемы с других форумов, эта проблема возникает по вине файловой системы (массово жалуются на ZFS), либо по причине проблем с самим диском. Как вариант, в пик нагрузки попробуйте посмотреть в сторону nmon или dstat (nmon более информативен). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 · Жалоба Я не совсем понимаю, какая связь между htb и хардом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
default_vlan Опубликовано 10 октября, 2017 · Жалоба 1 час назад, vasya_petrovich сказал: Я не совсем понимаю, какая связь между htb и хардом? Я считаю, что данная нагрузка на проц следствие чего-то более глобального, нежели чем первопричина. Я бы начал рассматривать от стандартного ввода/вывода: хард, память, сеть. Алгоритм такой: - Что будет, если в пиковую нагрузку отрубить сетку? - Как ведет себя память и жесткий диск в момент пиковой нагрузки? htb, насколько я понимаю, ничто иное как шейпирование трафика, поправьте, если не так. Насколько я помню, Iptables шейпировать трафик умеет, причем получше, чем любой другой сторонний софт. Тот же top позволяет посмотреть насколько то или иное прерывание валит проц. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 · Жалоба 34 минуты назад, default_vlan сказал: Я считаю, что данная нагрузка на проц следствие чего-то более глобального, нежели чем первопричина. Я бы начал рассматривать от стандартного ввода/вывода: хард, память, сеть. Алгоритм такой: - Что будет, если в пиковую нагрузку отрубить сетку? - Как ведет себя память и жесткий диск в момент пиковой нагрузки? htb, насколько я понимаю, ничто иное как шейпирование трафика, поправьте, если не так. Насколько я помню, Iptables шейпировать трафик умеет, причем получше, чем любой другой сторонний софт. Тот же top позволяет посмотреть насколько то или иное прерывание валит проц. Таблесы не умеют шейпировать трафик. Правда есть сторонний модуль, где-то тут на форуме пробегала тема, но там больше резалка, нежели шейпер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 10 октября, 2017 · Жалоба 8 часов назад, vasya_petrovich сказал: Получается, что где-то в htb какая-то бяка. Хотя там только классы, без фильтров. Это как так? А как трафик по классам раскидывается? Косяк в логике шейпера, где-то линейный перебор правил начинается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 10 октября, 2017 (изменено) · Жалоба 22 минуты назад, kayot сказал: Это как так? А как трафик по классам раскидывается? Косяк в логике шейпера, где-то линейный перебор правил начинается. Трафик классифицируется через ipset + skbprio Изменено 10 октября, 2017 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 12 октября, 2017 · Жалоба Есть небольшой прогресс. Где-то тут на форуме писали, что прибивать очереди к ядрам надо к "близлежащему процу". Перепривязал очереди, нагрузка резко упала на 15-20%. Гуру, объясните взаимосвязь? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 12 октября, 2017 · Жалоба Возможно особенности NUMA - адресация памяти соседнего проца очень дорого выходит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 13 октября, 2017 · Жалоба А почему бы hfsc не использовать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 13 октября, 2017 (изменено) · Жалоба 1 час назад, Alex/AT сказал: А почему бы hfsc не использовать? Что-то пока нет желания ))) Я не видел положительных отзывов, по крайней мере на НАГе, и у местных спрашивал, они не знают, как будет работать с hfsc. Те кто сталкивался с локами и отписывался здесь на форуме в конечном итоге ушли на полисер, а меня полисер не устраивает. Я тут на медне переписывался c иностранными админами, и у меня есть еще одно решение, которое я хочу попробовать. Дело в том, что на сетевухах интегрированных в моём серваке стоят BCM5709 (Broadcom NetXtreme II), а там очереди совмещенные RxTx, хочу перекинуться на интеловскую карту I350, где очереди разделенные RX отдельно и TX отдельно. Пробовал дрова компилить более свежие под bcm5709, но они на новом ядре не компилируются, и я особо не стал разбираться. Возможно есть какая-то опция в драйвере, которая делает разделенные очереди? Возможно, что тогда локов будет меньше. Отпишусь по результатам. Изменено 13 октября, 2017 пользователем vasya_petrovich Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stalker86 Опубликовано 13 октября, 2017 · Жалоба Скорее всего это аппаратная особенность чипа, что очереди совмещены Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 16 октября, 2017 · Жалоба В 13.10.2017 в 10:48, vasya_petrovich сказал: Что-то пока нет желания ))) Я не видел положительных отзывов По опыту (трёхлетней давности) могу сказать, что у HTB с lock contention полная задница. За последние годы оно чуть выровнялось, но не кардинально. Честно говоря, давно не глядел, но вроде бы на RCU его перевести нереально. Я использовал HFSC на BRAS достаточно долго, не могу сказать об этом шейпере ничего негативного. Свою задачу выполняет, иерархию поддерживает, в конфигурации не сложнее HTB. Производительность выше, lock contention был намного ниже. Ну и типовых болезней HTB, связанных с квантованием, у HFSC нет. И да, меняйте сетевухи таки на I350 или хотя бы на 82576. BCM5709 - это ужасный адаптер в плане производительности, несмотря на его 8 очередей. Хуже наверное только одноочередные 5708 и 82574... :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 16 октября, 2017 · Жалоба Переехал на Intel I350-T4. Ситуацию особо не улучшило, по всей видимости придется пробовать с hfsc. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 16 октября, 2017 · Жалоба 4 часа назад, Alex/AT сказал: И да, меняйте сетевухи таки на I350 или хотя бы на 82576. BCM5709 - это ужасный адаптер в плане производительности, несмотря на его 8 очередей. Хуже наверное только одноочередные 5708 и 82574... :) Это неправда. Поменял на нагруженном БРАСе bmc5709 на i340 - ничего не поменялось в плане загрузки и производительности. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pavel.M.A Опубликовано 16 октября, 2017 (изменено) · Жалоба 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 Изменено 16 октября, 2017 пользователем Pavel.M.A Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 17 октября, 2017 · Жалоба В 16.10.2017 в 12:43, kayot сказал: Это неправда. Поменял на нагруженном БРАСе bmc5709 на i340 - ничего не поменялось в плане загрузки и производительности. Значит упираетесь не в прерывания, ну или за последние годы что-то в ядре доработано. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vasya_petrovich Опубликовано 17 октября, 2017 · Жалоба Alex/AT, просим в студию вынести приз с вашим примером скрипта hfsc Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alex/AT Опубликовано 17 октября, 2017 · Жалоба 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'); Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...