Why our servers have 384, 576 or 1,152 GB of RAM

If you compare our server configurations, the memory sizes look unusual: 384, 576 and 1,152 GB rather than 256, 512 or 1,024. They follow from how the processor talks to its memory, and they give you all of the bandwidth the platform can deliver.

Memory channels in brief

A memory channel is an independent path between the processor's memory controller and the DIMMs attached to it. Channels work in parallel, so total bandwidth is roughly the bandwidth of one channel multiplied by the number of populated channels. Each DDR5 DIMM also splits its data path into two 32-bit subchannels, which improves efficiency, but the channel count is what you size by.

At DDR5-6000, one channel moves at most 48 GB/s in theory: 6,000 million transfers per second, 8 bytes each. Here is what that means across our range:

Real applications sustain less than these peaks. If your workload depends on bandwidth, measure it on the server with a tool such as STREAM.

One DIMM per channel

We populate every channel with exactly one identical DIMM, for three reasons.

1. Every channel contributes. Bandwidth scales with populated channels, so a socket with only 8 of its 12 channels filled delivers at most two-thirds of the peak.
2. Memory interleaves evenly. With identical DIMMs everywhere, consecutive blocks of memory are spread across all channels. Mixed sizes or uneven population leave regions that interleave across fewer channels, and performance varies depending on where your data lands.
3. Memory runs at full speed. One DIMM per channel lets the platform run at its highest supported memory speed. Adding a second DIMM per channel usually forces a lower speed.

Capacity therefore comes in multiples of 12 per socket:

The 48 GB and 96 GB modules are built on 24 Gb memory chips, a density introduced with DDR5. They fill the gaps between power-of-two sizes without breaking the one-DIMM-per-channel rule.

The GPU L40S, with 256 GB, is sized for a different job: on a single-GPU inference server, the model lives in the GPU's 48 GB of memory, so host memory matters less than on a database server.

Two channels on Core and Storage

The AMD EPYC 4005 processors in the Core and Storage series have two memory channels. That gives them far less memory bandwidth than a Pro server, in exchange for very high clocks: boosts of up to 5.4 GHz, or 5.7 GHz on the Core 16X. The Core 16X also carries 128 MB of L3 cache from 3D V-Cache, which keeps more hot data next to the cores.

For game servers, web applications and CI runners whose hot data fits largely in cache, clock speed matters more than memory bandwidth, and the Core series is the better value. For analytics scans, large in-memory datasets and dense virtualization, twelve channels win.

Bandwidth versus capacity

Memory sizing asks two different questions.

Capacity: does the working set fit? If it does not, the system reads from NVMe. That is fast for storage, but each access takes microseconds instead of the roughly 100 nanoseconds of DRAM, a gap of two to three orders of magnitude.

Bandwidth: how fast can the cores stream through it? Once data is in memory, analytics queries, in-memory column stores, large sorts and many HPC codes are limited by how quickly memory delivers it.

Dividing by core count shows the trade-off across the EPYC 9005 range. The bandwidth figures are theoretical peaks.

The Pro 32 gives each core the most bandwidth, which suits bandwidth-hungry work that does not scale across many cores. The Max servers give the most total capacity and total bandwidth, for workloads that spread across many cores and keep very large datasets in memory.

Sizing memory for databases

The goal is to keep frequently used data and indexes in memory, plus room for connections and the operating system.

• PostgreSQL relies on both its own buffer cache and the operating system's page cache. A common starting point is shared_buffers at about 25% of RAM, with the rest left to the page cache. work_mem applies per sort or hash operation, so many busy connections can multiply it.
• MySQL with InnoDB usually gets 60 to 75% of RAM for innodb_buffer_pool_size on a dedicated server.
• Redis keeps its whole dataset in memory. Leave headroom for background saves, which fork the process and can need significant extra memory under heavy writes.

Sizing memory for virtual machines

For production hosts, add up the memory of every VM, then reserve memory for the host and for storage caching, such as the ZFS ARC if you use ZFS. Ballooning and page merging can raise density, but a hypervisor that runs short of memory slows down every guest at once.

On the dual-socket Max 192, keep each VM within one socket's cores and memory where possible. Proxmox VE has a NUMA option per VM for this; our Proxmox guide covers host setup.

Check your server's memory layout

On Linux, you can see each DIMM, its size and its configured speed, as well as the NUMA layout:

dmidecode -t memory | grep -E '^\s+(Size|Locator|Configured Memory Speed):'
numactl --hardware

On a Pro or Max server you should see 12 populated slots per socket, all the same size.

To compare configurations, see the Pro series and the Max series, or read what EPYC 9005 changes for the rest of the platform. If you need a capacity that is not in the lineup, a custom build can keep every channel balanced.