ECC memory in a server: why it matters and how to check it
ECC memory stores an extra check code alongside every 64 bits of data. That lets the controller correct a single-bit error on the fly and detect a double-bit one, halting the machine instead of silently corrupting data. On plain memory such an error simply flips a value in RAM and nobody finds out — until the database falls apart.
- The SECDED scheme: a single error is corrected, a double error is detected and triggers a halt.
- Corrected errors are called CE, uncorrectable ones UE. The EDAC subsystem counts both.
- Without ECC a flipped bit looks like a random application crash that nobody can reproduce.
- Every ZevsHost dedicated configuration ships DDR4 ECC, from 16 to 64 GB.
- ECC only works as a chain: module, chipset and CPU must all support it at once.
How it works
For each 64 bits of payload the module adds 8 check bits, which is where the 72-bit bus and the ninth chip on the stick come from. On every read the memory controller recomputes the code and compares it with the stored one. A one-bit mismatch is corrected transparently for the application and the CE counter goes up.
A two-bit error cannot be corrected. The controller reports a UE and the kernel stops the system: a crash with a clear log entry beats writing a corrupted value into a database file. The CPU has to support it too, and server lines do — see choosing a server processor.
Module types
| Type | Correction | Where it is used | Characteristic |
|---|---|---|---|
| UDIMM non-ECC | None | Desktops, laptops | An error goes unnoticed |
| UDIMM ECC | SECDED | Entry-level single-socket servers | Capacity per channel is limited |
| RDIMM (registered) | SECDED | Xeon E5, Scalable and EPYC servers | Address buffering, more modules per channel |
| LRDIMM | SECDED | Builds from 256 GB upwards | Data buffering, higher latency |
Registered and unbuffered modules cannot be mixed in one machine: the platform simply will not post. Capacity per channel is capped as well, so plan upgrades from the motherboard documentation rather than from the number of empty slots.
What breaks without correction
- The database. A corrupted byte lands on disk with the InnoDB page; an integrity check finds it weeks later.
- Backups. An archive is assembled from data in memory, so the flipped bit travels into the copy you later restore from.
- The hypervisor. One error in a host memory page kills a guest, and debugging turns into hunting a bug that does not exist in the application.
- Encryption. Damage to a block while handling a key makes decryption impossible without a key backup.
How to verify ECC on a live server
Having ECC sticks does not prove correction is active. Check three things: memory type, EDAC activity and the error counters.
# Type, capacity and speed of the installed modules
dmidecode -t memory | grep -E 'Size|Type:|Speed|Locator'
# Whether the EDAC drivers are loaded (same on Debian/Ubuntu and RHEL)
lsmod | grep -i edac
# Corrected and uncorrectable error counters per controller
grep . /sys/devices/system/edac/mc/mc*/ce_count
grep . /sys/devices/system/edac/mc/mc*/ue_count
# Per-module summary via rasdaemon, saved to a file
ras-mc-ctl --error-count > /root/ecc-$(date +%F).txt 2>&1
On Debian and Ubuntu the tool comes from the rasdaemon package, and the RHEL family ships rasdaemon in the base repository. If dmidecode reports a type without the word ECC, there is no correction regardless of what the plan description says: this is the first thing to verify when accepting a new dedicated server.
A rising CE counter does not mean "fine, errors are being corrected". Single corrected errors mean one specific stick is degrading. UE usually follows CE, and a UE on a production machine is an unplanned halt in the middle of the working day.
Capture ce_count once a day and compare it with the previous value. Growth of tens of counts per day on one module is a reason to request a replacement stick, not to wait for the failure. Feeding these counters into monitoring alongside temperature and drive health is covered in server hardware monitoring.
When you need memtest and when EDAC is enough
EDAC reports errors on a running system and points at a specific module by slot number. It does not stress memory on purpose and only sees what happened during normal operation.
A full memtest86+ pass drives every address with patterns and catches defects that never surface under the production profile. Run it when accepting a machine and after replacing modules; the procedure is described in checking server RAM.
ECC in ZevsHost configurations
DDR4 with correction is installed in every dedicated server: 16 GB in the Start plans (from $49 per month in Germany), 32 GB in Pro, and 64 GB in Dedicated Enterprise US at $149. There is no cheaper non-ECC option in the range — on a server that saving pays off exactly once, right up until the first corrupted record. The configurations are listed on the dedicated server hosting page.
Key takeaways
- ECC corrects single-bit errors and halts the system on double-bit ones, keeping corrupted data off the disk.
- Verification takes a minute:
dmidecode -t memory, a loaded EDAC driver, and thece_countcounters. - A growing CE count is a signal to replace the module, not a sign of healthy operation.
- Registered and unbuffered modules do not mix, and per-channel capacity is limited by the platform.
- Every ZevsHost server carries DDR4 ECC, from 16 to 64 GB.