How to plan MU server capacity by number of players

Planning the capacity of an MU Online server is the exercise of translating an audience expectation into concrete hardware numbers: how many CPU cores, how many gigabytes of RAM, how much bandwidth, and what disk performance you need so that 100, 500, or 2000 players can play without lag during peak hours. Getting it wrong is expensive in both directions. Under-provisioning causes freezes, mass disconnects, and players fleeing right at launch. Over-provisioning burns budget on idle resources that could have gone to marketing. This guide shows a practical method for estimating capacity from the number of players, with reference formulas, examples, and a final checklist. The figures cited are working examples and vary by provider/version, so treat them as a starting point, not absolute truth.

Prerequisites

Before sizing anything, you need to be clear about what you will run and for whom:

• A version/emulator decision (Season 6, Season 15+, etc.), because consumption per player changes considerably between versions.
• An honest audience estimate: how many unique players and, above all, how many concurrent ones at peak.
• Access to a VPS or dedicated server provider that allows plan upgrades without a full reinstall.
• Monitoring tools installed (Task Manager/Performance Monitor on Windows, or perfmon) to measure real usage later.
• A working base server. If you have not built yours yet, start with the step-by-step guide on how to create an MU Online server and come back to size it.

Understand the difference between total and concurrent players

The number one mistake in planning is sizing by account count or by how many players "will join the server." What matters for hardware is the peak of concurrent players (CCU, concurrent users). A server can have 5000 registered accounts and never exceed 400 online at the same time.

A rule of thumb used by many administrators is to estimate peak CCU at between 8% and 15% of the active account base, depending on the time zone, the audience, and retention. If you expect 3000 active accounts, plan for a peak between 240 and 450 concurrent. This range varies by community/version, so adjust it as your own data comes in.

Always size for the peak, not the average. A server that handles the average but freezes during prime time loses players exactly when the most people are watching.

The four resources you need to size

MU server capacity is not a single number. There are four resources that run out at different rates:

The resource that saturates first is almost always the CPU, followed by the disk when the database is poorly indexed. RAM tends to be the most predictable and the cheapest to increase.

Step 1: Define the peak scenario

Start by writing down the concrete scenario you want to support. For example:

1. Expected peak of 500 concurrent players during prime time.
2. Distributed across 2 GameServers (channels) of 250 each.
3. With at least one mass event (Blood Castle, Devil Square, or an invasion) running during the peak.
4. A safety margin of 30% for launch and unexpected spikes.

Writing this down turns "I want a big server" into measurable requirements. The 30% margin matters: launches attract curious players who vanish later, and it is better to have headroom than to freeze in the first week.

Step 2: Estimate CPU per player

The CPU of an MU GameServer is dominated by a main thread that processes the game logic. This means the per-core frequency (clock) matters more than the raw core count for a single GameServer. Multiple GameServers, on the other hand, benefit from more cores because each process can occupy a different core.

A working estimate, which varies by provider/version:

Rule of thumb (example, no guarantee):
  ~150 to 300 players per GameServer per fast, modern core
  Mass events reduce that number by 20% to 40%

Scenario of 500 players across 2 GameServers:
  2 GameServers  -> 2 cores dedicated just to them
  + 1 to 2 cores for SQL Server
  + 1 core for the OS, ConnectServer, local site
  = target of 4 to 6 fast vCPUs

Prefer plans with dedicated vCPU ("dedicated CPU") over shared vCPU when the budget allows. Shared vCPU suffers from the "noisy neighbor" and produces unpredictable lag exactly at peak.

Step 3: Estimate RAM

RAM grows more linearly and predictably. You have a fixed base consumption (operating system, SQL Server, server processes) and an incremental consumption per player.

RAM estimate (example, varies by version):
  Windows Server OS            ~2 GB
  SQL Server (cache base)      ~2 to 4 GB (grows with the database)
  Each GameServer (base)       ~300 to 700 MB
  Per connected player         ~1 to 3 MB

Scenario of 500 players:
  2 GB (OS) + 3 GB (SQL) + 1 GB (2 GameServers) + 500 x 2 MB (~1 GB)
  = ~7 GB in use -> plan for 12 to 16 GB for headroom and cache

Always leave headroom for the SQL Server cache. A database that fits in RAM answers queries much faster than one that has to read from disk on every query.

Step 4: Estimate the network

Each player in the game exchanges a small, constant stream of packets with the server: movement, combat, chat, surroundings updates. Consumption per player is low individually, but it adds up in aggregate.

Bandwidth estimate (example, varies by emulator):
  Normal play:    ~3 to 8 KB/s per player
  Mass event:     can double due to entity density

Scenario of 500 players at peak with an event:
  500 x 6 KB/s (average) = ~3,000 KB/s = ~24 Mbps sustained
  + margin -> hire a link of at least 100 Mbps symmetric

More important than raw bandwidth is usually the quality of the network: low, stable latency, and anti-DDoS protection. A 1 Gbps link with no attack mitigation goes down at the first flood; a 100 Mbps link with good mitigation keeps the server online.

Step 5: Size the disk and the database

The disk tends to be the forgotten resource until the day the server "freezes for 2 seconds every minute." That is almost always disk I/O during character saving or unindexed queries.

Practical rules:

1. Use NVMe SSD, never HDD, for the database. The difference in I/O latency is brutal.
2. Reserve space for the database, logs, and backups to grow: an active database grows continuously.
3. Ensure indexes on the most-queried tables (characters, accounts, inventory). A missing index can make CPU consumption explode with few players.

A simple query to track the slowest queries in SQL Server:

-- Top 10 queries by total execution time
SELECT TOP 10
    total_elapsed_time / execution_count AS avg_ms,
    execution_count,
    SUBSTRING(st.text, 1, 200) AS trecho_query
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY total_elapsed_time DESC;

Step 6: Build the sizing table by tier

With the estimates above, you can build a reference table by player tier. The values below are examples that vary by provider/version and serve as a starting point for requesting quotes:

Note that from around 800 players on, the recommendation becomes separating the database and considering multiple hosts. Scaling vertically (one ever-larger machine) has a limit; scaling horizontally (more GameServers, a dedicated database) is the path for large populations.

Step 7: Validate with a load test before launch

An estimate is a hypothesis; a test is a fact. Before opening to the public, validate the sizing:

1. Stand up the server on the chosen plan.
2. Simulate load with test accounts or a load-bot tool (respecting your community's and provider's rules).
3. Force a mass event while monitoring CPU, RAM, network, and disk I/O.
4. Watch where the first resource crosses ~70% sustained usage. That is your real bottleneck.
5. Adjust the plan or configuration and repeat.

The goal is to keep the four resources below 70% at the simulated peak, leaving 30% of headroom for the surprises of launch.

Common errors and fixes

Release checklist

• I defined a realistic concurrent-player peak, not the total account count.
• I chose the version/emulator and considered its consumption per player.
• I sized the CPU prioritizing fast clock and dedicated vCPU.
• I reserved RAM with headroom for the SQL Server cache.
• I calculated network bandwidth and confirmed the provider's anti-DDoS mitigation.
• I used NVMe SSD and indexed the most-queried tables in the database.
• I built the sizing table by tier and chose the plan with a 30% margin.
• I ran a load test forcing a mass event before opening.
• I confirmed that no resource exceeds 70% at the simulated peak.
• I verified that the provider allows fast upgrades without reinstallation.

Planning capacity is not guessing the future, it is reducing uncertainty to defensible numbers. Start with the concurrent peak, size the four resources separately, leave a margin, and validate with a test. With this method you enter launch knowing exactly what your infrastructure can handle and with a clear upgrade path for when the server grows.

Frequently asked questions