«Уведомление об ограничении мощности» на серверах Dell 12G с RHEL6


9

Сервер: Poweredge R620
ОС: RHEL 6.4
Ядро: 2.6.32-358.18.1.el6.x86_64

Я испытываю тревоги приложений в моей производственной среде. Критически ресурсоемким процессам не хватает ресурсов, что приводит к отставанию в обработке. Проблема возникает на всех серверах Dell 12-го поколения (r620) в недавно развернутом кластере. Насколько я могу судить, случаи этого происходят до максимальной загрузки ЦП, сопровождаемой огромным количеством спама «уведомления об ограничении мощности» dmesg. Выдержка из одного из этих событий:

Nov  7 10:15:15 someserver [.crit] CPU12: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU6: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU14: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU0: Package power limit notification (total events = 11)
Nov  7 10:15:15 someserver [.crit] CPU6: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU14: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU18: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU20: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU2: Package power limit notification (total events = 12)
Nov  7 10:15:15 someserver [.crit] CPU10: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Core power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU4: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU16: Package power limit notification (total events = 13)
Nov  7 10:15:15 someserver [.crit] CPU20: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU8: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU10: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU22: Package power limit notification (total events = 14)
Nov  7 10:15:15 someserver [.crit] CPU15: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU3: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU1: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU5: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU15: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU3: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU1: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU5: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU19: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU17: Package power limit notification (total events = 377)
Nov  7 10:15:15 someserver [.crit] CPU9: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU21: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU23: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU11: Core power limit notification (total events = 369)
Nov  7 10:15:15 someserver [.crit] CPU13: Package power limit notification (total events = 376)
Nov  7 10:15:15 someserver [.crit] CPU7: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU19: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU9: Package power limit notification (total events = 374)
Nov  7 10:15:15 someserver [.crit] CPU21: Package power limit notification (total events = 375)
Nov  7 10:15:15 someserver [.crit] CPU23: Package power limit notification (total events = 374)

Небольшой Google Fu показывает, что это, как правило, связано с перегревом процессора или включением регулятора напряжения. Хотя я не думаю, что это происходит. Датчики температуры для всех серверов в кластере работают нормально, политика ограничения мощности отключена в iDRAC, и мой системный профиль установлен на «Производительность» на всех этих серверах:

# omreport chassis biossetup | grep -A10 'System Profile'
System Profile Settings
------------------------------------------
System Profile                                    : Performance
CPU Power Management                              : Maximum Performance
Memory Frequency                                  : Maximum Performance
Turbo Boost                                       : Enabled
C1E                                               : Disabled
C States                                          : Disabled
Monitor/Mwait                                     : Enabled
Memory Patrol Scrub                               : Standard
Memory Refresh Rate                               : 1x
Memory Operating Voltage                          : Auto
Collaborative CPU Performance Control             : Disabled
  • Сообщение в списке рассылки Dell описывает симптомы почти идеально. Dell предложила автору попробовать использовать профиль Performance, но это не помогло. В итоге он применил некоторые настройки в руководстве Dell по настройке сервера для сред с низкой задержкой, и одна из этих настроек (или их комбинация), похоже, устранила проблему.
  • В сообщении Kernel.org № 36182 отмечается, что отладка прерываний по ограничению мощности была включена по умолчанию, что приводит к снижению производительности в сценариях, когда начинается регулирование напряжения ЦП.
  • В статье RHN KB (требуется вход в RHN) упоминается проблема, влияющая на серверы PE r620 и r720, на которых не работает профиль производительности, и рекомендуется обновить ядро, выпущенное две недели назад. ... За исключением того, что мы запускаем профиль производительности ...

Все, что я могу найти в Интернете, приводит меня в круг. Что, черт возьми, происходит?


1
К вашему сведению, эта проблема была исправлена в основном ядре 3.11. Это связано с тем, что обработчик прерываний ядра запускает это «нормальное» некритическое событие. Привязка, связанная выше, отключает этот обработчик.
Тотор

Ответы:


8

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

Несмотря на некоторую дезинформацию со стороны Redhat, все связанные страницы ссылаются на одно и то же явление. Регулирование напряжения происходит с профилем производительности или без него, вероятно, из-за включенной функции Turbo Boost . Вне зависимости от причины, эти колебания напряжения плохо взаимодействуют с прерываниями ядра с ограничением мощности, которые включены по умолчанию в ядре 2.6.32-358.18.1.el6.x86_64.

Подтвержденные обходные пути:

  • Обновление до самого последнего выпущенного ядра Redhat (2.6.32-358.23.2.el6) отключает эту отладку и устраняет проблему производительности.
  • Добавление следующих параметров ядра grub.confотключит PLN:clearcpuid=229

Flaky обходные пути:

  • Настройка системного профиля «Производительность». Этого само по себе было недостаточно для отключения PLN на наших серверах. Ваш пробег может варьироваться.

Плохие обходные пути:

  • Добавление в черный список модулей, связанных с ACPI. Я видел это в нескольких темах форума. Опрометчивый, так что не надо .

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

@ewwhite Эти серверы были развернуты непосредственно перед тем, как эти обновления ядра были запущены. Новый RPM был доступен 16 октября .
Андрей Б

Grrr для Red Hat. Хорошая находка.
13

Даже после обновления эта проблема появилась у меня через несколько недель (в ядре 2.6.32-431.17.1.el6.x86_64). Нам пришлось отключить PLN, используя clearcpuid, чтобы на этот раз избавиться от него. Эта проблема уже вызвала у меня столько головных болей! И у нас только один сервер Dell 12G (и из-за этого он останется единственным).
Мартин

1
@Martijn В данный момент мы 2.6.32-431.11.2.el6.x86_64не сталкиваемся с проблемой. Множество кластеров, высокие нагрузки и т. Д. Вполне возможно, что регрессия могла начаться, когда Redhat выпустил это обновление пять дней назад. Я дам вам знать, что я найду, и обновлю ответ, если обнаружу, что это так.
Андрей Б,
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.