ARK Ascended RAM Growth: Sizing Server Memory for Day 14, Not Day 1

ARK: Survival Ascended has the least forgiving memory profile of any dedicated game server in production today. A fresh server with a handful of players can sit at 6–8 GB of RSS, then climb past 20 GB after two weeks of real base building, taming, and map exploration. If you size RAM from a one-hour test on day one, you will OOM-kill a live server inside a fortnight. This article breaks down where the memory actually goes, how to measure the growth curve, and what headroom to buy. Infrastructure choice matters here: 32 GB of fast DDR5 and a kernel you can tune changes the equation far more than a higher slot count on paper. Start from a bare-metal platform sized for game workloads rather than a burstable VPS, because ARK’s allocator does not shrink back politely.

Why ASA RAM Grows and Never Comes Back

The ASA server process is a single Unreal Engine 5 binary. Its memory is organised into three pools: the UE object graph (structures, dinos, players, inventories), the cooked asset working set (streamed textures, meshes, audio), and allocator fragmentation on top of both. The object graph grows with persistent world state — every foundation you place is an actor, every tamed dino holds inventory and AI state. Fragmentation grows because UE’s allocator carves buckets from a large virtual reservation and rarely returns pages to the OS. The result on a Linux host is an RSS curve that is monotonically increasing with a bumpy slope.

Measured on a 20-player PvE cluster over 14 days, the typical shape looks like this per server instance:

Note the drive figure: UE reserves significant virtual address space that is never touched, so “VIRT” in top is meaningless for sizing. RSS is what the OOM killer sees.

Measuring the Growth Curve Properly

Do not size from ps. Sample RSS and PSS once a minute into a time-series database so you can see the slope rather than a snapshot. A two-line probe is enough:

• awk '/VmRSS/ {print $2/1048576 " MiB"}' /proc/$(pgrep -f ShooterGameServer)/status every 60 s, logged with the timestamp.
• smem -P ShooterGameServer -c "pid pss rss" hourly, to separate shared asset pages from private memory.

Run this for at least one full player-activity cycle — a weekday evening plus a weekend peak. The useful number is the 95th-percentile peak per slot-day: MB of RSS added per active player per 24 hours. On the server above it was ~160 MB per active player per day, decaying to ~90 MB/day once the tribe stopped expanding. That decay is the difference between “it will eventually die” and “it stabilises” — and it only appears if you measure past day ten.

Sizing Rule: Peak Plus Slope Plus Margin

A workable formula for ASA:

• Baseline: 8 GB for the fresh process, plus 1.2 GB per configured slot.
• Map and mod overhead: each additional map in rotation costs 2.5–3.5 GB resident while loaded; total conversion mods can double that.
• Growth allowance: 7 days × 100 MB per active player, capped at 60% of baseline.
• Headroom: 25% free RAM, minimum 4 GB, so the page cache and the restarted process can coexist during a graceful restart.

For a 20-slot PvE instance that arithmetically lands at 8 + 24 + 8.4 + 6 ≈ 46 GB — which is why 64 GB per node is the sane floor for two ASA instances, and 128 GB is where clusters stop paging. If you run one instance per node, 32 GB works only with aggressive nightly restarts and a strict base-part cap.

Reducing Growth Without Cutting Content

You cannot stop actor growth, but you can slow the allocator side and bound the worst case:

• Set MALLOC_ARENA_MAX=2 and, on glibc builds, test MALLOC_MMAP_THRESHOLD_=131072. This caps per-thread arenas and measurably flattens RSS drift on multi-threaded UE servers.
• Disable transparent_hugepage=always; madvise is the safe setting. Forced THP inflates tail latency on UE allocation spikes and swells RSS by 5–8%.
• Cap structures per tribe in your server config. Every foundation is a permanent actor; base sprawl is the single largest contributor to day-14 RSS.
• Schedule a restart during the low-pop window and warm it with a scripted player join so the asset working set is preloaded before the evening rush.

Restart Windows Are Part of the RAM Budget

If your plan is “restart nightly to reclaim memory”, you need room for two processes briefly: the dying server writing its final save and the new one loading the map. On a 32 GB node running one instance at 19 GB, that overlap will swap. Either drain and stop before starting the replacement (30–90 s downtime) or budget the second process. Monitoring restart duration over time is also your canary: a restart that grows from 40 s to 3 minutes means the save is bloating, not just memory.

What Hardware Actually Helps

ASA is memory-bandwidth and single-thread bound. A high-clock CPU with 8–12 fast cores per instance beats a 32-core part clocked low; DDR5-5600 ECC with 12 channels keeps allocator lock contention from showing up as tick spikes. NVMe matters mostly at save time — a 12 GB save written to a saturated SATA SSD will stall the tick thread for seconds.

Bandwidth per instance is the other constraint people underestimate. A 70-player ASA server under load moves 6–9 Mbps out and 3–4 Mbps in, but the packets are small enough that the limit appears as packets-per-second rather than bits. A 1 Gbps uplink handles roughly eight busy ASA instances before softirq cost, not bandwidth, becomes the bottleneck. When you are evaluating a host, ask how many instances share a physical port and whether the NIC has multiple queues.

Mods and Cluster Transfers Change the Curve

Two ASA behaviours break the linear model. First, cluster transfers: when a player uploads a dino or an item stack to the cluster, the receiving map allocates new actors that persist after the transfer. On a five-map cluster with active transfers, we saw the receiving instance grow 1.5–2 GB per day faster than a non-clustered one. Second, total conversion mods: they replace the asset working set, and the resident footprint after a map load can jump by 40–60% even if the mod adds little gameplay.

• Log cluster transfer volume per map per day. If one map absorbs most transfers, give it extra headroom rather than equal shares.
• Stagger map restarts so two memory-hungry maps do not cold-load simultaneously on the same node.
• Cap uploaded dino count per player if the cluster is large; inventory payloads are the largest single-actor allocations we have observed.

If you are choosing between providers, ask for the actual memory spec (speed, channels, ECC) and for a node you can reboot on your own schedule, because ARK’s growth curve makes scheduled restarts non-negotiable. You can compare current dedicated server configurations built for persistent game worlds and check the RAM per node before you commit. The short version: size for day 14, not day 1, and keep 25% free or the OOM killer will do your capacity planning for you.