Solo or with friends
The one-player light-zone run peaked at 2.56 GiB of world memory; this calculator keeps a 2.8 GiB planning floor. Four GiB total RAM is tight when the database and OS share the machine.
For home hosts and communities
Plan your EQ2Emu server.
Running a world for yourself, a few friends, or a larger group? Compare the CPU, RAM, and loaded zones your setup may need, then choose a sensible first test.
How we estimated this →A practical starting point
Start with your own setup.
Enter the computer you have or the number of people you expect. We show a starting configuration or load-test size, plus what to watch. The result is not a guaranteed player limit.
Count loaded zones
Zones can stay loaded for 300–600 seconds after a player leaves, and some stay longer. Include those alongside zones where someone is playing.
Watch one busy zone
Players spread across zones are different from a crowd in one city. Average CPU and RAM can look healthy while a crowded zone lags.
Calculating a starting point…
Behind the numbers
Why this is a starting point.
Small-world RAM
The current one-player, three-loaded-zone run peaked at 2.56 GiB. The calculator retains a higher light-world planning floor; your OS, database, login service, and web tools need separate memory.
More zones and maps
At 400 synthetic players, peak world memory rose from 102 loaded zones to a distinct-map 302-zone selection. The same number of zones can also differ greatly by map content.
Players per zone
At 400 players, 24 per zone had no long main-loop intervals in one short run; 48 grew a network queue, and 64 had 36 intervals over 100 ms. There is no universal safe cap.
A crowded city
Earlier single-zone runs exposed update-round delays as players gathered, even when whole-world CPU was spare. Enter a likely busiest-zone population to see this warning.
Measured examples: solo and friends
Current jemalloc build, 120-second synthetic holds in light introductory and small-room maps, with two other zones loaded. MariaDB and the client generator were outside the world allocation. These are worldserver observations, not total home-PC use or a player limit.
| Players | Occupied / loaded zones | Mean CPU cores | Peak world RAM | World threads |
|---|---|---|---|---|
| 1 solo | 1 / 3 | 0.034 | 2.56 GiB | 23 |
| 6 together | 1 / 3 | 0.044 | 2.56 GiB | 23 |
| 6 spread | 2 / 4 | 0.046 | 2.56 GiB | 26 |
| 12 together | 1 / 3 | 0.053 | 2.45 GiB | 23 |
| 12 spread | 3 / 5 | 0.059 | 2.61 GiB | 29 |
The non-monotonic memory peaks reflect allocator and zone-selection differences; they do not mean adding players saves RAM. The calculator retains a 2.8 GiB light-world planning floor. With OS, MariaDB, and login on the same machine, 2 vCPU / 8 GiB is a sensible small-group starting test; 2 vCPU / 4 GiB has little headroom. More or larger loaded zones, or a game client on the same PC, can require more.
Measured example: four players per zone
Worldserver alone, 180-second synthetic holds. The 100–300-player rows use the newer build; the 400-player row is the previous build and remains the zone-layout anchor. These are observations, not player limits.
| Players | Occupied / loaded zones | Mean CPU cores | Peak world RAM | Zone threads + overhead |
|---|---|---|---|---|
| 100 | 25 / 27 | 0.29 | 3.09 GiB | 95 |
| 200 | 50 / 52 | 0.54 | 3.17 GiB | 170 |
| 300 | 75 / 77 | 0.87 | 3.39 GiB | 245 |
| 400 | 100 / 102 | 1.11 | 4.40 GiB | 320 |
All rows had populated main-loop p99 in the 16.384-ms histogram bucket and no measured intervals over 100 ms. More players in one zone or different maps can change the result sharply.
Read the test method and calculator limits
These are local Linux Release screens on a Core Ultra 9 275HX with four allocated logical CPUs, jemalloc, version-843 headless sessions, movement at 8 Hz, and a self-cast every five seconds. MariaDB and the generator were outside the world allocation. Small-group holds lasted 120 seconds; 100–400-player holds lasted 180 seconds. The 400-player runs vary occupied-zone density and selected maps; they supply the zone-layout CPU/RAM curve. Matched 100/200/300-player runs on the newer build, at four players per zone, calibrate its lower-population CPU estimate. The new 1/6/12-player cases check the conservative low-end estimate for a few light maps; their lower RAM peaks are not applied as a universal discount because map selection and allocator state vary. Older 100/200/300-player single-zone runs supply latency warnings only; they used an earlier build and are not current CPU/RAM anchors.
The newer groundspawn/map-allocation work reduced the 100-empty-zone sampled peak by 266 MiB, but has not been rerun across the 400-player layout matrix, so no blanket saving is subtracted. The measured populated layouts stop at 400 players and 302 loaded mostly-distinct-map zones (202 shared-map zones). Beyond those points, the calculator extends the last observed zone slope, allows 2 MiB per additional player, and adds a planning allowance that grows 20% for each additional measured-range multiple. These are heuristics, not measured confidence bounds. The CPU reserve for other programs is your estimate, not a measured database/game-client CPU result. Each additional world peer repeats substantial startup memory. The 20,000-player/zone input guard is for calculator safety, not a capacity claim. Busy-zone latency, heavy content, arrival bursts, co-hosted software, and processor differences may invalidate a projection before its resource budget is reached.
Source reports in EQ2Emu source: docs/performance/sizing-small-host-2026-10-02.md, docs/performance/sizing-population-calibration-2026-10-02.md, docs/performance/jemalloc-current-capacity-screen-2026-10-01.md, docs/performance/spawn-movement-filter-2026-09-30.md, docs/performance/zone-load-memory-2026-10-02.md, and tools/capacity/SIZING.md.