CentOS 7. Kernel panic — not syncing: Fatal machine check on current CPU

Провайдер услуг: ovh

Проц: Intel Xeon D-1521

ОС: CentOS 7.3

Ядро: 3.14 кастомное от ovh

Дело было на майских праздниках. Клиент, держащий сервис, написанный на php и использующий mysql как бд, попросил посмотреть, почему сервер внезапно перестаёт отвечать.

Предположили, что дело может быть в высокой нагрузке и отваливается сеть. Но нет, нагрузка так себе, на интерфейсе максимум 300 pps, трафик низкий, память не кушается, проц процентов на 40% загружен. В процессе выяснилось, что сервер не только перестаёт отвечать, но и сам перезагружается.

Ага! Настраиваем kdump. kdump не запускается на кастомном ядре 3.14 ovh. Ставим ванильное из родных реп

Пересоздаём конфиг для загрузчика (grub2, да)

Грузимся в ванильное ядро, где kdump корректно работает.

Выловились такие ошибки при каждом ребуте

Дело ясное — проблема в процессоре! Пишем в поддержку ovh с описанием проблемы. Нам отвечают, что да, похоже на проблемы с железом, но неплохо бы прогнать тесты, так что загрузитесь по pxe в наш специальный rescue-image и вперёд.

Далаем тесты. 64GB оперативки… ждём…

Тесты говорят нам, что всё в порядке О_О Как так? Нельзя просто заменить проц, чтобы всё было хорошо? Перезагружаем сервер и видим, что centos всё так же продолжает свой kernel panic.

Зато пока гнались тесты, нагуглились похожие проблемы, и, проанализировав их, появилось предположение, в которую нужно копать — питание и частота процессора (ну да, логично)

CPUs didn’t answer in synchronization*

Идём в БИОС, ищем Advanced Power Management, начинаем читать… EIST и C-STATE позволяют снижать частоты процессора для экономии электроэнергии и уменьшения уровня шума. И они как раз включены. Отключаем.

Ребут. Запуск. Нагрузка. Работает!

Итого, мы имеем ядро, которое не умеет работать с некоторыми функциями относительно новых процессоров intel (D-1521 октябрь 2015). Вероятно, есть способ побороть это со стороны ОС.


Upd.: после сделанных изменений аптайм стал дольше, но внезапные ребуты, хоть и реже, но остались. Поддержка невнятная, онлайн проекту нужен срочно, поэтому клиент переехал на linode.


3.14.32-xxxx-grs-ipv6-64 3.10.0-514.16.1.el7.x86_64 4.11.0-1.el7.elrepo.x86_64 4.4.66-1.el7.elrepo.x86_64
CentOS 7 Kernel panic — not syncing Kernel panic — not syncing Kernel panic — not syncing см.ниже

[20131.766316] perf interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 50000

[21855.799002] conntrack: generic helper won’t handle protocol 47. Please consider loading the specific helper module.

[66335.445024] Kernel panic — not syncing: Timeout: Not all CPUs entered broadcast exception handler

Если мне когда-нибудь удастся протестировать с этим процессором, например, ubuntu 16.04.2 с ядром 4.8, то дополню заметку, как она ведёт себя при включённых EIST и C-STATE.

Добавить комментарий

Ваш e-mail не будет опубликован.