Choose resources for a game server

A game server needs enough memory to hold the world and the players, enough CPU to simulate them, and enough network capacity to send them data. This article explains how to estimate those needs for your player count, measure your current server, and decide when to resize.

Before you begin

• An Ubuntu 24.04 LTS VPS that you can reach over SSH, with a sudo user (this guide uses alex).
• A rough idea of your plans: how many players you expect at peak, and what kind of game you will run. This guide focuses on Minecraft Java Edition, but the method works for most game servers.
• Patience to measure. The first estimate is a starting point, and the real numbers come from watching the server with players on it.

Step 1: Plan for players and world activity

Resource needs grow with three things: the number of players online at once, how far apart they spread out, and how much of the world they change. A few friends building in one area need much less than twenty players exploring, mining and running farms across a large map. Write down three numbers before you start: expected peak players, planned view distance (the default is 10 chunks), and whether you plan to run plugins or mods, since those add load.

Step 2: Check what your server has now

Before you judge a plan, learn what the current VPS provides. These commands are read-only, so they are safe to run at any time:

nproc
free -h
df -h /
uptime

Each command reports one thing. nproc prints the number of CPU cores. free -h shows total and available memory in human-friendly units. df -h / shows free disk space on the main drive, which the world and backups both need. uptime prints the load average, which is a rough measure of how busy the processor is. Expected output looks like this, with your numbers instead:

2
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       412Mi       2.9Gi        10Mi       540Mi       3.4Gi

A load average near or above the number of cores, sustained over time, means the CPU is the bottleneck.

Step 3: Estimate memory

For a vanilla Minecraft Java server, memory is usually the first limit. The Java heap, set with -Xmx, holds the world and player data. Java also needs extra memory beyond the heap, and the operating system needs its own share. A practical rule for planning:

• Up to about 5 players, with a modest world: 2 GB total for the server, with a heap of about 1.5 to 2 GB.
• About 10 to 20 players: plan for 4 GB or more, with a heap of 3 to 4 GB.
• Heavy modpacks or many plugins: budget more, and measure before you commit.

Leave at least 1 GB free for the operating system and Java's own overhead, so the heap never fights the rest of the system for memory. These figures are starting points, not guarantees. Check them against real use.

Step 4: Estimate CPU and bandwidth

Minecraft's main thread runs on a single core, so a server with two strong cores is usually better than one with many weak ones. As a rough starting point, a small vanilla server works on one or two vCPUs, and a server with 10 to 20 players usually benefits from two. Exploration, redstone, and large farms all spike CPU use, so leave headroom.

Bandwidth is driven by the number of players and how fast they move through new terrain. Each player typically uses well under a megabit per second, but new chunks loading as players travel cause short bursts. Check the monthly transfer allowance in your plan, and think about how many hours per month your server will be online.

Step 5: Measure under real load

The best data comes from a busy evening. Install a process viewer and watch the server while players are connected:

sudo apt update
sudo apt install -y htop
htop

In htop, the bars at the top show CPU use per core, and the memory bar shows used RAM. Look for the Java process, named java, and note its memory column. Press q to quit. If memory stays near the limit or the CPU bars sit near 100 percent during peaks, you need more resources.

For network use over days, the vnstat tool records traffic in the background. Install it with sudo apt install -y vnstat, then check the daily totals after a day of data has built up with vnstat -d.

Step 6: Decide whether to resize

Use your measurements to decide. If the server is comfortable at peak, your current plan is fine. If memory is tight, or the CPU is busy at peak, move to a larger plan. LightServe offers the Wisp, Cirrus and Nimbus plans, and their specifications are listed on the LightServe plans page, so you can compare the CPU, memory and transfer figures against the numbers you measured. Choose a plan with headroom, because players and world size tend to grow over time.

Troubleshooting

• The server lags at peak but memory looks fine: the CPU is the limit. Lower the view distance, reduce entity-heavy farms, or move to a plan with more cores.
• Java crashes with "OutOfMemoryError": the heap is too small for the load. Raise -Xmx if the plan has room, or reduce players and view distance.
• Disk fills up quickly: old backups and log files take space. Check with df -h / and sudo du -sh /opt/minecraft/*, then remove what you no longer need.
• Load average is high with few players: another process may be using the CPU. Look for it in htop and stop what you do not need.

Next steps

With a plan that fits your numbers, you are ready to install the server. Continue with the Minecraft Java server article, which sets the heap size in the start command. After that, the systemd and backup articles keep the server running reliably.