RAM, Cores and Chunk Count: What Actually Limits a Minecraft Server
Why more RAM and more cores rarely fix a lagging Minecraft server, how single-thread speed, loaded chunks and entities set the real limit, and what to change first.
ChunkPod Team · · 8 min read
RAM, Cores and Chunk Count: What Actually Limits a Minecraft Server
A Minecraft server slows down for reasons that don't line up with what most people buy first. Owners upgrade to more RAM, then pick a plan with more cores, and are still stuck at 15 TPS with ten players online. The bottleneck is usually somewhere else: how fast one CPU core is, and how many chunks the server is trying to keep alive at once.
RAM sets a floor, not a ceiling
RAM is the resource that gets talked about most because hosts sell it by the gigabyte and it's the easiest number to compare. That framing is misleading.
A Minecraft server needs enough memory to hold its loaded chunks, its entities, the JVM's own overhead, and any plugins or mods you've added. Once you've cleared that floor, adding more RAM doesn't make the game run faster. It gives the garbage collector more room to work, which can smooth out pauses, but it doesn't raise your TPS.
The point where more RAM stops helping comes sooner than most owners expect. A vanilla or Paper SMP for a handful of friends is usually fine on 4 to 6 GB. A busy modded server on Forge, NeoForge, Fabric or Quilt with a heavy modpack might genuinely need 8 to 12 GB. Past that, extra RAM mostly means longer garbage collection pauses when they eventually happen, not more headroom to work with.
If your server is running at 12 TPS with 10 GB assigned to the JVM, moving to 16 GB will not fix it. Something else is eating the tick.
Cores don't scale the way you'd think
The other big number on a hosting plan is the core count. Minecraft is famously bad at using them.
The main game loop, the thing that runs a tick 20 times a second, is single-threaded. Every block update, redstone signal, hopper transfer, mob AI decision and player action for every loaded chunk has to fit inside 50 milliseconds on one core. If it takes longer, TPS falls, everything slows down, and your players feel it as choppy movement and laggy hits.
Recent Paper versions and Folia have started to break some of this work out onto other threads, and mod loaders offload things like world I/O, but the core simulation is still bound to one core on almost every server people run. That means a CPU with 32 slower cores will lose to a CPU with 8 faster ones for Minecraft, every time.
What this means in practice:
- Single-thread performance is the number that matters, not the total core count.
- More cores help a little for chunk saving, network I/O, plugins with async tasks and running multiple servers on the same box, but they don't raise the TPS ceiling of one server.
- A proxy like Velocity in front of two smaller servers can use extra cores better than one large server can.
If a host advertises 8 cores without saying anything about clock speed or CPU generation, that number tells you almost nothing about how the server will actually tick.
Loaded chunks are the real workload
Here is where the story gets more useful. What actually eats your tick is loaded chunks.
Every chunk the server is keeping active is 16 by 16 columns of blocks that it has to tick. Grass grows, crops mature, fire spreads, water flows, redstone updates, mobs think about pathfinding, hoppers pull items, and dispensers wait for signals. Multiply that by the number of chunks in memory and you get the server's real workload.
Two settings decide how many chunks are loaded around each player:
- view-distance in server.properties, which sets how many chunks the server sends to clients so they can render them.
- simulation-distance, added in Minecraft 1.18, which sets how many chunks are ticked (mobs move, crops grow, redstone runs) around each player.
For a long time, view distance did both jobs, and cranking it up was the fastest way to kill a server. Now they're split. You can send players a wide view for the sightlines and simulate a smaller ring around them for the game logic.
A rough starting point:
- Small SMP with strong hardware: view 10, simulation 6 to 8.
- Busy public server: view 8, simulation 4 to 6.
- Modded server with heavy machinery mods: view 6, simulation 4, and expect to tune it further.
The default view distance of 10 is often too high for a public server with 20 players online. Ten players at view 10 means the server is holding a lot of chunks in memory, ticking most of them, and serializing block updates for all of them to every nearby client.
Entities are chunks with legs
Once you accept that ticking chunks is the workload, entities follow the same logic. Every mob, item frame, armor stand, dropped item, minecart and boat is a thing the server has to think about every tick.
The classic offenders:
- Mob farms that hold thousands of hostile mobs in a small area for grinding.
- Item elevators and sorting systems full of dropped items that never despawn because a hopper keeps picking them up and putting them back.
- Villager trading halls with hundreds of villagers pathing around.
- Storage rooms with walls of active hoppers pulling from double chests.
Paper's paper-world-defaults.yml and Spigot's spigot.yml both expose knobs for this. Entity activation range decides how close a player has to be before a mob starts thinking. Mob spawn limits cap how many hostile, passive and ambient mobs can exist per player. Hopper transfer settings decide how often hoppers check for items to pull.
Two servers with the same player count and the same view distance can tick very differently just because one of them has three big mob farms and the other doesn't.
Pregenerated worlds pull the spike out
The single laggiest thing a Minecraft server does is generate new terrain. Building a chunk from scratch involves noise sampling, feature placement, structure decisions and, in modded, whatever your worldgen mods want to add. When a player sprints towards a border no one has been past, the server has to build every new chunk on the main thread, and TPS craters until it's caught up.
Pregeneration solves this by doing that work in advance. Plugins like Chunky on Paper, Spigot and Purpur, or mods with the same idea, generate a defined radius of chunks while the server is quiet, save them to disk, and then serve them from storage instead of building them on demand.
Combine this with a world border set at a fixed radius and you have a server where:
- New terrain is never generated during peak hours.
- The size of the world on disk stops growing after the pregen finishes.
- Backups take a predictable amount of time and space.
For a survival server aimed at 20 to 50 players, a 5000-block radius pregen is usually plenty. Modded servers with dimensions like the Nether and the End need pregen for each of them, sized down because their worldgen is slower.
Startup flags: give the JVM a hand
RAM won't raise your TPS, but the JVM flags you use decide how the memory you have gets managed. The default flags Mojang ships with are fine for a private server and not much more.
Two commonly used sets are Aikar's flags, tuned for G1GC on Paper-style servers, and MeowIce's flags, which target ZGC on modern Java versions. Both aim to keep garbage collection pauses short so the tick loop isn't interrupted while it's trying to hit its 50 millisecond budget.
Picking flags by hand is fiddly because they depend on your Java version, the RAM you're giving the server and the server software you're running. ChunkPod's JVM Arguments Generator at chunkpod.com/tools/jvm-arguments outputs a ready set for the RAM size, server type and preset you pick, so you don't have to memorize every flag.
What to change first
If a server is struggling, the order of operations that usually helps most is:
- Check TPS with a profiler like Spark. Find out which system is eating the tick before touching anything.
- Lower view distance and simulation distance. The gains show up immediately.
- Look at entity counts. Cap or clean up mob farms, adjust entity activation range, tune hopper settings.
- Pregen the world and set a border.
- Update to newer JVM startup flags matched to your Java version.
- Only then look at whether RAM or the underlying CPU is actually the limit.
Most servers never need to get past step 4. The ones that do usually find they need a faster CPU core, not a bigger plan.
If you'd rather not run the box yourself, ChunkPod is a Minecraft server host in early access. Hosting isn't open to the public yet, but you can join the waitlist at chunkpod.com.