Провайдер услуг: ovh
Проц: Intel Xeon D-1521
ОС: CentOS 7.3
Ядро: 3.14 кастомное от ovh
Дело было на майских праздниках. Клиент, держащий сервис, написанный на php и использующий mysql как бд, попросил посмотреть, почему сервер внезапно перестаёт отвечать.
Предположили, что дело может быть в высокой нагрузке и отваливается сеть. Но нет, нагрузка так себе, на интерфейсе максимум 300 pps, трафик низкий, память не кушается, проц процентов на 40% загружен. В процессе выяснилось, что сервер не только перестаёт отвечать, но и сам перезагружается.
Ага! Настраиваем kdump. kdump не запускается на кастомном ядре 3.14 ovh. Ставим ванильное из родных реп
yum install kernel
Пересоздаём конфиг для загрузчика (grub2, да)
grub2-mkconfig -o /boot/grub2/grub.cfg
Грузимся в ванильное ядро, где kdump корректно работает.
Выловились такие ошибки при каждом ребуте
[ 617.734479] Disabling lock debugging due to kernel taint
[ 617.734483] mce: [Hardware Error]: CPU 4: Machine Check Exception: 5 Bank 4: be00000000800400
[ 617.734490] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81390207> {intel_idle+0xd7/0x160}
[ 617.734491] mce: [Hardware Error]: TSC 22f02fc14382 ADDR ffffffff81390200 MISC ffffffff81390207
[ 617.734493] mce: [Hardware Error]: PROCESSOR 0:50663 TIME 1493660122 SOCKET 0 APIC 1 microcode 700000a
[ 617.734494] mce: [Hardware Error]: Run the above through 'mcelog --ascii'
[ 617.754549] mce: [Hardware Error]: Some CPUs didn't answer in synchronization
[ 617.754550] mce: [Hardware Error]: Machine check: Processor context corrupt
[ 617.754551] Kernel panic - not syncing: Fatal machine check on current CPU
Дело ясное - проблема в процессоре! Пишем в поддержку 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.
