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.
Measurements and assumptions →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
More players exploring means more zones stay awake. Zone hopping starts new zones while earlier ones can wait 5–10 minutes or longer to sleep. The calculator adds an automatic travel allowance.
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…
Measurements and calculator assumptions
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.
Test method and limits
The automatic travel allowance adds two baseline zones plus the larger of the occupied-zone count or one zone per five concurrent players, rounded up. This is a planning assumption, not a measured travel rate. Players can hop through several zones before earlier ones sleep after 300–600 seconds or longer; always-loaded rules and frequent travel can require a higher manual count. The measured tables above used only two other loaded zones, so their totals differ from automatic estimates.
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.