ECC Memory on a Server: What It Protects and What It Does Not

ECC memory stores extra check bits with every word of data, so the memory controller can correct a single flipped bit and detect a double bit error instead of silently handing corrupted data to your program. That is the whole point of an ECC memory server. Every voxa.host dedicated server ships with registered ECC memory: DDR4 on the Xeons, DDR5 on the EPYCs.

How ECC memory works

ECC stands for error correcting code. A DDR4 module moves 64 bits of data per transfer, and an ECC module is 72 bits wide: the extra 8 bits hold a check code the memory controller computes on every write and verifies on every read. The textbook scheme is SECDED, single error correction with double error detection. One wrong bit in a word is flipped back. Two wrong bits are reported as uncorrectable.

Server platforms often go further. Schemes sold as Chipkill or single device data correction spread each word across many DRAM chips so that even one dead chip can be corrected, depending on the processor, firmware and DIMM layout. Most server memory controllers also patrol scrub, fixing single bit errors in the background before a second one lands in the same word.

Registered versus unbuffered ECC

Registered ECC memory (RDIMM) adds a register chip that buffers command and address signals between the memory controller and the DRAM chips. That lowers the electrical load on each channel, so a server can run more and larger modules, at the cost of about one extra clock cycle of latency. Unbuffered ECC (ECC UDIMM) leaves the register out and suits workstations. The EPYC 9004 platform takes registered DDR5 only. On a dual socket board each processor has its own memory controllers and DIMMs, the basis of NUMA on dual socket servers.

Where bit flips come from, and why scale matters

Three things flip bits in DRAM. The first is particle strikes: cosmic rays produce showers of neutrons in the atmosphere, and one passing through a memory cell can deposit enough charge to change its value. That is a soft error, and the cell works normally afterwards. The second is electrical noise and marginal signal timing, made worse by heat. The third is ageing or failing DIMMs, which produce hard errors that return at the same address.

The chance that any one bit flips in a given hour is tiny, but 128 GB is roughly 1.1 trillion bits, and the 1024 GB of DDR5 in a Dual EPYC 9754 is roughly 8.8 trillion. Multiply that by months of uptime and a rare event becomes routine. A 2009 field study of Google's server fleet, "DRAM Errors in the Wild", found that about a third of machines saw at least one correctable memory error in a year. Errors also tended to repeat on the same machines, which points at failing hardware more than random particles.

DDR5 on die ECC is not ECC memory

Every DDR5 chip contains on die ECC. Cells became so small that manufacturers added a correction step inside each chip, fixing a single bit error before the data leaves the chip. That is why desktop DDR5 spec sheets mention ECC at all.

It is not ECC memory, for two reasons. On die ECC stops at the edge of the chip, so nothing checks the data on its way across the module, connector and motherboard to the memory controller. And the chip corrects silently: the controller never learns an error happened, the operating system gets no report, and a slowly failing chip gives you no warning.

ECC DIMMs add side band ECC on top. Extra DRAM chips widen each 32 bit subchannel so the memory controller stores its own check bits next to the data, verifies them across the whole path and reports every corrected and uncorrected error. Desktop DDR5 is not ECC memory. The DDR5 in our EPYC servers is registered ECC with side band check bits, on top of the on die ECC every DDR5 chip already has.

When ECC is not enough

An uncorrectable error stops the machine

When the memory controller finds an error it cannot fix, the processor raises a machine check. Depending on the platform and where the bad data sits, Linux either kills the process that touched the page and takes the page out of service, or halts the machine with a kernel panic. Either way it refuses to carry on with data it knows is wrong.

That is safer for a database. PostgreSQL and InnoDB write every change to a write ahead log first, so after a crash they replay it and return at the last committed transaction. A silent bit flip has no such recovery: the wrong value is committed, streamed to replicas and copied into backups, and may surface months later.

What ECC never sees

• Software bugs. A program that writes the wrong value writes it with valid check bits.
• Errors beyond its strength. Three or more flipped bits in one word can be miscorrected or slip through. Stronger codes narrow this gap without closing it.
• Data already damaged on disk or in transit. A failing SSD, a bad cable or a corrupted upload arrives in memory already wrong, and ECC then protects the wrong bytes.

Layers that cover the gaps

• Filesystem checksums. ZFS and Btrfs checksum every data block and verify it on read. With a mirror or RAIDZ, ZFS repairs a bad block from a good copy, and a regular scrub finds damage before you need the data. ext4 and XFS checksum metadata but not file contents.
• Database page checksums. InnoDB checksums every page by default. PostgreSQL can checksum data pages too, a setting chosen when the cluster is initialised.
• Backups you have restored. A backup counts once you have restored it and checked the data. Our guide to automating server backups covers schedules and retention.

Watching memory errors on Linux with EDAC

The kernel's EDAC subsystem (error detection and correction) exposes counters in sysfs under /sys/devices/system/edac/mc. Each memory controller gets a directory such as mc0, with ce_count for corrected and ue_count for uncorrected errors since boot. Per DIMM or per rank directories below it carry their own counters and a label naming the slot. The driver is amd64_edac on the EPYCs and sb_edac on the Xeon E5s, and the kernel log prints a line starting with EDAC for each event.

The counters reset at boot, so also install rasdaemon, packaged for Debian, Ubuntu, AlmaLinux, Rocky Linux and most other distributions. Enable its service with systemctl and it records every corrected and uncorrected memory event, plus machine checks and PCIe errors, in a database that survives reboots. The reporting command that ships with it prints errors per DIMM.

An isolated corrected error means ECC did its job. A corrected count that keeps rising on the same DIMM is the early warning that the module should be replaced, often well before the first uncorrectable error. Open a ticket with the DIMM label, the corrected and uncorrected counts and the dates. Any uncorrected error deserves a ticket straight away.

Do you need ECC RAM? The workloads that care most

The ECC vs non ECC RAM question comes down to one comparison: what costs you more, a crash or a wrong answer nobody notices? These workloads sit firmly on the wrong answer side.

Workload	What a silent bit flip could do	Layer that catches it
Relational database	Commit a wrong value that replicas and backups copy faithfully	ECC in memory, page checksums on disk, tested restores
Long running VMs	Damage a guest's memory and crash a VM weeks later	ECC, plus EDAC monitoring to replace a weakening DIMM early
ZFS storage host	Store a block damaged in RAM with a checksum that says it is fine	ECC before the checksum, ZFS scrubs after it
Financial calculations	Produce a balance or price that is wrong but plausible	ECC, plus reconciliation against an independent record
Scientific computing	Return a wrong result after days of compute	ECC, plus checkpoints and repeated runs that must agree
Build servers	Ship a corrupted binary or poison a shared build cache	ECC, plus reproducible builds compared by hash

For a database, the EPYC 9254 pairs 24 Zen 4 cores boosting to 4.15 GHz with 128 MB of L3 cache, 128 GB of registered DDR5 and 2 × 1 TB NVMe for €485 a month, built to order in about 14 days. See our database server guide, or sizing a database on a VPS if a smaller machine may do.

For RAM heavy work such as large caches or a virtualisation host full of VMs, the Dual Xeon E5 2699 v4 gives you 44 cores, 88 threads and 256 GB of registered DDR4 for €325 a month, about €1.27 per GB, delivered in about 45 minutes.

Questions we get

Does ECC memory make a server slower?

Only slightly. The check runs in hardware inside the memory controller, and registered modules add about one clock cycle of latency. How much that shows depends on the workload.

Does ZFS need ECC memory?

ZFS runs without it, but its checksums are computed from data in RAM. A bit that flips before that point is stored with a valid checksum and reported as healthy forever. ECC protects data in memory, and ZFS protects it on disk.

Can I order a server with more memory?

Ask support before you order. Memory upgrades depend on the hardware available at the location you choose and are quoted per server. Any extra modules match the installed type: registered ECC DDR4 on the Xeons and DDR5 on the EPYCs.

Pick a server with ECC already inside

Every voxa.host dedicated server ships with registered ECC memory, from 128 GB of DDR4 on the Dual Xeon E5 2630 v3 to 1024 GB of DDR5 on the Dual EPYC 9754. Start with the EPYC 9254 for databases or the Dual Xeon E5 2699 v4 for RAM heavy work, or compare all dedicated servers. Whichever you pick, install rasdaemon on day one.