ARK Cluster Hardware Sizing: Multi-Map CPU Pinning, Save Bloat and Mod Load

ARK Cluster Hardware Sizing: Why It Is Different

An ARK cluster is not one server. Most communities run three to eight maps (Island, Ragnarok, Extinction, Aberration, Genesis, plus custom mod maps) that transfer characters, dinos, and items between each other. Each map is a full Unreal Engine server process with its own world, its own save, and its own tick loop. That makes cluster sizing a packing and pinning problem as much as a raw-spec problem. Admins planning a cluster should compare dedicated server plans by core count and clock rather than by headline RAM.

One Map, One Heavy Process

ARK is a 2015-era Unreal title with a notoriously heavy single-thread tick and a large, constantly-growing save. A single map with a few dozen players is already a serious workload.

Multiply those numbers by the number of maps. A six-map cluster of mature maps can realistically consume 96-160 GB of RAM before you even discuss the OS and page cache. That is the moment a single box stops making sense and cluster sharding begins.

CPU Pinning: Isolate Maps to CCDs

ARK servers do not scale across many threads; they benefit from being left alone. The most effective technique is CPU pinning so each map process stays on a fixed set of cores within one CCD (or one NUMA node). This lifts hit rates in L3 and prevents the scheduler from bouncing a map’s hot thread across cache domains.

• Assign each map its own CCD/CCX on AMD, or its own NUMA node on dual-socket Intel
• Pin the main map thread to the highest-boost core in the group
• Reserve 1-2 cores per map for async save and networking so they do not steal tick time
• Never let two heavy maps share an L3 slice if you can avoid it
• Leave the first core complex to the OS and management, not to maps

On a 16-core single-socket board you can comfortably run three to four maps pinned to their own CCDs while leaving room for the OS. Beyond that, a second node keeps tick times honest.

Save Bloat Is the Cluster Killer

ARK saves grow almost without bound. Every tamed dino, every structure, every dropped item persists. A mature cluster can have 30-60 GB of total save data, and each map writes its entire save on an autosave interval. That produces short, violent write bursts that stall the tick loop.

This is exactly the write-amplification and endurance problem that cheap SSDs handle badly. Plan for NVMe with a high drive-writes-per-day rating and enough spare area, and keep backups on a separate volume so a save burst does not fight a backup job for IOPS.

Mod Load Multiplies Everything

Cluster mods are non-negotiable on most servers (stacking, structures plus, custom dinos, cluster transfer helpers). Each mod adds startup cost, memory, and tick handlers. A heavily modded map can add 30-50% to RAM and noticeably increase save size and load time.

• Baseline mods (5-15): +10-20% RAM, minimal tick cost
• Heavy mod set (30-60): +30-50% RAM, measurable tick cost
• Mods that add structures/dinos: grow save size and autosave burst
• Always benchmark with the real mod list, not vanilla

Cluster Configuration Tiers

If you are building a cluster, see our dedicated server comparison to line up core counts and NVMe capacity against the number of maps you intend to run.

For turnkey bare-metal with fast provisioning, see InterServer dedicated servers.

Bottom line: ARK cluster sizing is about per-map resources and CPU pinning, not aggregate core count. Give each map its own CCD and RAM budget, put saves on high-endurance NVMe to absorb the bloat bursts, and shard to a second node once tick times start drifting above your target.