Центр Диагностики & База Системных Ошибок

Решения для Windows Server, Active Directory, 1С, СУБД, Linux, Cisco, MikroTik и IP-телефонии.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, баз данных и сетевого оборудования. Перед выполнением действий обязательно создайте резервную копию. При отсутствии необходимой квалификации обратитесь к ИТ-специалистам.
EDAC MC0: UE (Uncorrectable Error) Linux / DevOps

EDAC MC0: UE (Uncorrectable Error) — Фатальный сбой ECC памяти в Linux

Обновлено: 18.08.2026  ·  Официальная база знаний

Архитектура ошибки и симптомы сбоя

Критический сбой «EDAC MC0: UE (Uncorrectable Error) fatal memory hardware error» регистрируется при возникновении многобитовой ошибки в оперативной памяти (Multi-Bit ECC Error). В отличие от однобитовых сбоев, алгоритмы ECC не способны восстановить поврежденные биты данных. Во избежание записи искаженных данных в СУБД или на диск ядро немедленно останавливает систему через MCE (Machine Check Exception) или аварийно завершает затронутый процесс.

Диагностическая таблица параметров сбоя

ПараметрЗначениеИнженерный смысл сбоя
UE (Uncorrectable Error)Multi-Bit FlipНеисправимое аппаратное повреждение данных в оперативной памяти.
ActionMCE Panic / SIGBUSЯдро вызывает панику либо отправляет SIGBUS процессу-владельцу страницы.
Hardware StateDefective DIMMФизический выход из строя чипа памяти на планке DIMM.

Пошаговое дерево решений и сценарии траблшутинга

Сценарий 1: Определение точного физического адреса и слота DIMM

# Просмотр аппаратных фатальных событий через rasdaemon:
sudo ras-mc-ctl --summary

# Проверка логов mcelog:
sudo mcelog --client

# Анализ журнала IPMI SEL:
sudo ipmitool sel list | grep -E "(Uncorrectable|Critical)"

Сценарий 2: Проверка механизма изоляции страниц (Memory Failure Recovery)

В современных ядрах включена подсистема CONFIG_MEMORY_FAILURE, которая пытается мягко изолировать поврежденную 4KB страницу памяти (Soft/Hard Offline):

# Проверка статуса изолированных страниц ядра:
cat /proc/meminfo | grep -i "HardwareCorrupted"

Сценарий 3: Немедленная замена дефектного модуля памяти

  1. Зафиксируйте маркировку слота из логов IPMI (например, DIMM_B2).
  2. Выключите сервер, замените дефектный модуль памяти на заведомо исправный с аналогичными таймингами и ранговостью (1R/2R/4R).
  3. Перед вводом в production выполните стресс-тест ОЗУ с помощью memtest86+.
Критический сбой оборудования на узле кластера?
ITSTM обеспечивает экстренную миграцию рабочих нагрузок, замену серверных комплектующих и настройку резервных нод высокой доступности (HA Cluster).
Практический опыт инженера: При частых сбоях UE на разных модулях памяти одного сокета замените процессор или проверьте сокет материнской платы на наличие погнутых ножек (LGA pins).

Частые вопросы (FAQ)

Может ли ошибка UE привести к повреждению базы данных?

Да, если сбойная ячейка памяти содержала страницу буферного кэша СУБД до того, как аппаратный контроллер успел сгенерировать исключение MCE. После сбоя UE рекомендуется провести проверку целостности таблиц БД.

Почему сервер не ушел в перезагрузку при ошибке UE?

Если поврежденная страница принадлежала пользовательскому процессу, а не ядру, Linux изолирует страницу (Hard Offline) и убивает только этот процесс сигналом SIGBUS (BUS_MCEERR_AR).