ARK: Survival Ascended Dedicated Server CPU 100-300%: What's Normal, When to Upgrade
An ARK: Survival Ascended dedicated server that reports 154%, 197%, or even 280% CPU in the host panel is not necessarily overloaded. ASA runs as a multi-threaded Unreal Engine 5 binary under Wine or Proton on Linux hosts, and the CPU number is summed across worker threads. This article maps observed CPU figures to plan capacity, explains the parts of the ASA cost stack you can actually control, and gives you the cgroup signal that tells you whether the server is throttled or just busy.
Per-Core Math First
Linux reports CPU as a percentage where one fully-busy core is 100%. ASA spawns four to eight worker threads, so the host can legitimately report 400–800% during an active fight or boss event without anything being wrong. A two-core plan caps at 200%; a four-core plan caps at 400%.
| Observed sustained CPU | 2-core plan | 4-core plan | 6-core plan |
|---|---|---|---|
| 100-150% | Healthy headroom | Idle | Idle |
| 150-200% | At ceiling, expect lag spikes | Healthy | Idle |
| 200-300% | Throttled, upgrade | Heavy load, OK | Healthy |
| 300-500% | N/A | At ceiling | Heavy load, OK |
| 500-800% | N/A | Throttled, upgrade | At ceiling |
What the Logs Look Like When Things Are Normal
ASA's main runtime log is at ~/arksa/data/Saved/Logs/ShooterGame.log. The following lines are typical and not problems:
[2026.05.26-02.38.08:264][586]Garbage Collection Triggered! bDoForcePurge 1, bForcePurge 0, bIsAsyncLoading 0, NumPendingUnreachable 1726 (full purge threashold 25000), bSurpassedUnreachableObjectsFullPurgeThreshold 0, bTryCollectGarbageResult 1
[2026.05.26-02.52.48:519][956]2026.05.26_02.52.48: Saving world...
[2026.05.26-02.52.48:530][956]2026.05.26_02.52.48: World Save Complete. Took: 1.046944
[2026.05.26-00.37.41:327][ 5]Attempted GC & Defrag: Start: 8.21 GB End: 8.19 GB 0.02 GB Free'd, Duration: 0.352941 seconds
[2026.05.26-00.37.41:327][ 5]Server: "<session-name>" has successfully started!
[2026.05.26-00.38.11:400][230]Server has completed startup and is now advertising for join. (10.24GB Mem)
[2026.05.26-00.37.47:193][ 5]Full Startup: 107.34 seconds
[2026.05.26-00.37.47:193][ 5]Number of cores 24"Full Startup: 107.34 seconds" is the upper end of healthy cold-start time on TheIsland_WP. Anything past three minutes warrants investigation. The 15-minute save cadence with a sub-2-second save duration is the healthy baseline.
What Indicates an Actual Problem
Look in the same log for any of the following:
Attempted GC & Defrag: Start: 8.21 GB End: 8.19 GB 0.02 GB Free'd, Duration: 12.482941 secondsA garbage-collection sweep that takes longer than five seconds is a stutter the players feel. The "Free'd" delta also matters — a multi-second GC that frees less than 100 MB means the working set is too big to evict.
LogStreaming: Warning: Loading Texture took ...LogPerfCounters: tick rate dropped below ...LogNet: NotifyAcceptingConnection accepted from: ...
LogNet: Closing connection [UNetConnection] Driver: ...Repeated connection drops with no visible client-side cause point at the server failing to maintain its tick rate, not at a network problem.
The cgroup Throttle Counter Is the Real Signal
The host CPU percentage tells you whether the server is busy. The cgroup throttle counter tells you whether the host is actively capping it. On Supercraft hosts this is exposed per-server, and the read is non-destructive.
cat /sys/fs/cgroup/system.slice/u<port>.slice/cpu.statThe line that matters is nr_throttled. On a healthy server this number stays at zero across an entire play session. On a server hitting its plan ceiling it climbs every few seconds. The throttled_usec value tells you how many microseconds the kernel held the server back over the lifetime of the process.
The host panel's CPU percentage and the cgroup throttle counter answer different questions. A server can show 150% CPU and still be heavily throttled if the plan cap is 100%. The CPU number is what the server tried to use; the throttle counter is what the kernel let it use. Always check both before deciding to upgrade.
The ASA Cost Stack You Can Control
- Wine/Proton overhead. Every ASA Linux server pays a 10–15% baseline tax. This is fixed cost — nothing you do server-side reduces it.
- Map choice. TheIsland_WP is the lightest official map. Ragnarok_WP, Valguero_WP, and Astraeos add measurable cost from larger world bounds and more spawn zones. Switching from Astraeos to TheIsland_WP on the same plan often drops sustained CPU by 30–40%.
- Player slot count. Every connected player adds 2–5% CPU. A 32-slot server with 24 active players will sit 50–120% higher than the same server empty.
- Mod count and weight. Each CurseForge mod with runtime systems — Awesome SpyGlass, S+, custom dinos, expanded cooking — adds measurable cost. Ten mods is heavy; twenty is the upgrade signal.
- Difficulty multipliers.
OverrideOfficialDifficultyset above 5 increases spawn density.DifficultyOffset=1.0on top of that does the same. Higher difficulty means more dinos in memory, more pathing calculations per tick. - Structure count per tribe. A megabase with 30,000 structures costs more per tick than ten well-built homes spread across the map. Structure decay enforcement helps here.
Verifying the Cost of Each Change
The startup commandline is logged at boot. You can confirm what flags are actually in effect:
Commandline: "TheIsland_WP?listen?SessionName=<session-name>?RCONEnabled=True?RCONPort=<port+3>" -port=<port> -WinLiveMaxPlayers=32 -NoBattlEye -newsaveformat -servergamelog -ServerPlatform=ALL -PublicIPForEpic=... -QueryPort=<port+1> -AllowFlyerSpeedLevelingNo -mods= flag in that line means the server is running vanilla. If you have CurseForge mods active through the panel and do not see them on the commandline, the mod loader is being applied a different way and is still counted toward runtime cost.
When to Upgrade the Plan
The combination that justifies an upgrade is all four of the following over a 3-day window:
- Sustained CPU above 80% of plan ceiling during active play (e.g. above 320% on a 4-core plan).
nr_throttledclimbing during peak hours.- Player reports of rubber-banding, dinos teleporting, or chat lag.
- Garbage collection durations regularly above three seconds.
Any one of those in isolation can be a transient. All four together means the server has outgrown the plan. The host panel's resource-pressure diagnostics will surface a measurement-backed recommendation if those conditions are met — use that rather than guessing.
When CPU Is Not the Real Problem
Sustained CPU is often the symptom, not the cause. Two common cases:
- Memory pressure. If the server is paging or hitting its memory limit, GC runs constantly to keep the working set under the ceiling. CPU appears high because GC is expensive. Fix memory first; CPU will follow.
- Disk I/O contention. If world-save duration regularly exceeds five seconds, the saves are competing with another tenant for the same disk queue. Move to a less-busy node, not a bigger plan.
What's Worth Checking Next
tail -200 ~/arksa/data/Saved/Logs/ShooterGame.log | grep -E "GC|Save|Startup|Number of cores"That one command surfaces the GC duration, save duration, startup time, and core count. If any number is outside the healthy ranges in this article, that is your diagnostic anchor.
When to Escalate
Contact support with the last 500 lines of ShooterGame.log attached if all of the following are true:
- You have already trimmed map, mods, and slot count.
- cgroup
nr_throttledis still climbing during peak hours. - The panel's resource-pressure recommendation still suggests upgrade after the trim.
For ARK: Survival Ascended servers sized to your actual mod and player load, see ARK: Survival Ascended hosting plans on Supercraft. Plans scale by core count, not just RAM, and the resource-pressure check is built into the panel.
Last updated: 2026-05-26.
Looking for managed ARK: Survival Ascended server hosting? Supercraft runs ASA dedicated servers with right-sized CPU, daily backups, instant setup, and 5 region options. Plans from $5.99/mo.