Перевірка оперативної пам'яті сервера: memtest86+ і EDAC
Оперативну пам'ять виділеного сервера перевіряють двома способами. Офлайн — завантаженням memtest86+ із зовнішнього образу: тест пише й читає шаблони за всіма адресами і знаходить дефект точно, але сервер цей час не працює. Онлайн — читанням лічильників підсистеми EDAC у ядрі Linux: вона реєструє кожну помилку, яку виправив ECC, і ловить деградацію модуля за тижні до відмови.
- ECC виправляє одиночні бітові помилки й записує факт у EDAC: каталог
/sys/devices/system/edac/mc/. - Зростання
ce_countна одному DIMM — привід міняти модуль, навіть якщо сервер працює без збоїв. - Помилка UE (uncorrectable) означає, що дані вже зіпсовані: сервер виводять з роботи одразу.
- Усі виділені сервери ZevsHost ідуть із DDR4 ECC: від 16 GB на Start до 64 GB на Enterprise US.
EDAC проти memtest86+: що чим ловиться
EDAC (Error Detection And Correction) — це драйвери ядра під конкретні контролери пам'яті Intel і AMD. Вони не тестують пам'ять, а знімають те, що контролер уже порахував: скільки одиночних помилок виправлено (CE) і скільки подвійних виправити не вдалося (UE). Пам'ять при цьому працює під вашим реальним навантаженням, а не під синтетичним шаблоном.
memtest86+ працює інакше: він вантажиться замість ОС, забирає всю пам'ять собі й проганяє по ній тести move inversions, випадковими та «ходячими» одиницями. Так знаходять дефекти, які ECC виправляє мовчки, і помилки адресації, коли запис за однією адресою псує іншу.
| Метод | Простій потрібен | Що знаходить | Коли застосовувати |
|---|---|---|---|
| EDAC (sysfs) | ні | лічильники CE/UE по контролерах і слотах | постійно, у моніторингу |
| memtester | ні | дефекти у вільній частині пам'яті | швидка перевірка на живій машині |
| memtest86+ | так, години | дефекти комірок і адресації по всьому обсягу | приймання, заміна модуля, розбір аварії |
На прийманні нового сервера обидві перевірки роблять до перенесення даних — порядок дій розібрано в статті про приймання виділеного сервера.
Онлайн-перевірка через EDAC
Лічильники в sysfs
Перевірте, що драйвер завантажено, і зніміть лічильники. На серверних Xeon E3 і E5 це зазвичай sb_edac, ie31200_edac або skx_edac.
# драйвер EDAC завантажено?
lsmod | grep -i edac
# сумарні лічильники по контролерах пам'яті
grep -H . /sys/devices/system/edac/mc/mc*/ce_count
grep -H . /sys/devices/system/edac/mc/mc*/ue_count
# розбивка по слотах: скільки помилок і як слот підписано в BIOS
grep -H . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count
cat /sys/devices/system/edac/mc/mc0/dimm0/dimm_labelНулі в усіх файлах — нормальний стан. Будь-яке ненульове значення в ue_count вважайте аварією. Ненульовий ce_count сам по собі не вирок, важлива динаміка: зніміть значення, зачекайте добу, зніміть знову.
memtester: перевірка без перезавантаження
memtester тестує лише ту пам'ять, яку зміг виділити процесу, тому ядро та зайняті сторінки він не покриє. Для швидкого відсіювання цього вистачає: якщо дефект потрапляє в перевірювану область, він спливає за хвилини.
# вільна пам'ять у мегабайтах
free -m
# тест 4 GB, 3 проходи, вивід у файл
memtester 4096M 3 > /var/log/memtester.log 2>&1
# чим завершилося
grep -i -E 'failure|ok' /var/log/memtester.log | tail -n 20Не запускайте memtester на обсяг, близький до загального. Процес блокує пам'ять через mlock, і ядро відправляє в OOM-killer базу даних, вебсервер і все інше, що працювало на машині. Беріть не більше 60–70 % від значення free, а на навантаженому сервері — не більше 25 %. Перевірити, що ви нікого не поклали: dmesg -T | grep -i oom має мовчати, а systemctl --failed — показувати порожній список.
Офлайн-прогін memtest86+
Повноцінний тест вимагає завантаження замість ОС. На виділеному сервері це роблять через IPMI та KVM-over-IP: підключаєте ISO як віртуальний привід і обираєте завантаження з нього. Опція доступу KVM/IPMI коштує $5/міс на всіх тарифах, окрім Dedicated Enterprise US, де вона вже включена.
Другий шлях — встановити пакет у систему, він додасть пункт у меню завантажувача.
# Debian/Ubuntu: пункт memtest86+ у меню GRUB
apt-get install -y memtest86+
update-grub
# перевірити, що пункт з'явився
grep -i memtest /boot/grub/grub.cfgОрієнтуйтеся на час: повний прохід по 16 GB DDR4 займає близько двох-трьох годин, по 64 GB на Enterprise US — майже добу. Закладайте щонайменше два проходи поспіль, а під час пошуку плаваючого дефекту — чотири.
Що робити зі знайденими помилками
- Поодинокий CE за місяць. Записати й спостерігати. Це може бути частинка космічного випромінювання, заради якої ECC і придумали.
- Десятки CE на добу на одному DIMM. Модуль деградує, плануйте заміну в найближче вікно.
- Будь-який UE. Негайно знімайте навантаження: невиправлена помилка вже могла потрапити у файл бази або в сторінку кешу.
- Помилки мігрують між слотами. Справа не в модулях: дивіться на контролер пам'яті, процесор і налаштування таймінгів у BIOS/UEFI.
Чому ECC узагалі вартий того й чим серверна пам'ять відрізняється від десктопної, розібрано окремо в статті про ECC-пам'ять у сервері. Конфігурації за обсягом пам'яті на кожному тарифі дивіться на сторінці виділених серверів.
Коротко
- Лічильники EDAC дають раннє попередження без простою; memtest86+ дає доказ, але вимагає зупинки.
- Стежте за динамікою
ce_countпо слотах, а не за самим фактом ненульового лічильника. - Будь-яка UE — привід вивести сервер з роботи, не чекаючи вікна обслуговування.
- Для офлайн-тесту підключіть ISO через IPMI і закладайте від двох повних проходів.