How to Reduce RAM Usage on a Minecraft Server Without New Hardware

High RAM use on a Minecraft server is rarely a hardware shortfall. It's a measure of how much your config asks the server to hold in memory at once, and you can shrink that with config changes alone, without spending a cent. This is for someone running their own Paper or Spigot server who's seeing memory pressure or garbage-collection lag — if you just want to get on a server, joining a server is a different problem and you can stop here.

The goal isn't a smaller number for its own sake. Lower steady-state memory means the garbage collector has less to scan each pass, so its pauses get shorter and your TPS stays steadier.

What actually fills the heap

Three things eat the most memory: loaded chunks, entities, and plugin or mod data. Player count itself is cheap — a few hundred MB per player at most on a heavy modded pack, and less than that on vanilla. So if you're memory-bound, it's usually not the people, it's what the world is doing around them.

Loaded chunks are the first big one. Every player keeps a ring of chunks loaded and ticking around them, and the more spread out your players are, the more those rings multiply instead of overlapping. View-distance and simulation-distance set how big that ring is, which makes them the most direct lever you have.

Entities are the second. Mobs, villagers, item drops, XP orbs, minecarts, item frames — the server tracks and ticks all of them. Farms, grinders, and redstone contraptions push those counts up fast, and a high entity count both pressures the heap and triggers the GC pauses that show up as TPS drops. Plugin and mod data is the third: each one carries its own caches, database connections, and background tasks, and a few will quietly leak memory over a long uptime.

Before you change anything, install Spark and profile the running server so you tune the actual hog instead of guessing. Watch TPS alongside memory while you're in there — the two problems look similar from the outside but they don't have the same fix.

Tune view-distance and simulation-distance

This is the single biggest win you can get from config alone, and the trick is to stop treating the two settings as one. Simulation-distance controls what the server actively ticks, which is the expensive part. View-distance controls how far chunks stay loaded so players can see them. They don't need to match.

A good starting point for most populated servers is view-distance 6 to 8 with simulation-distance 4. Players still see plenty far because their own client render distance fills in the horizon, but only the nearby ring actually costs your server CPU and memory. The default view-distance of 10 is too high once you have a real player count — every notch you drop it cuts how many chunks sit in the heap per person.

These live in server.properties, and Paper lets you set them per-world too, so you can keep a busy survival overworld lean while leaving a small hub alone. The gain scales with concurrent, spread-out players, so the more crowded your server gets, the more this one change pays back.

Cap and despawn entities

Entities are your second lever, and there are a few settings that work together. Lower mob caps and tighter despawn ranges both cut how many entities the server is holding and ticking at any moment.

Paper's per-player-mob-spawns spreads spawns fairly across players, so you can lower the overall caps without leaving anyone standing in an empty world waiting for a mob to show up. Despawn ranges are the bigger handle, though. Vanilla defaults are soft 32, hard 128 — mobs past the soft range have a per-tick chance to despawn, and mobs past the hard range despawn immediately. Tightening these toward a soft range around 28 to 32 and a hard range of 64 to 96 cuts the number of tracked entities sharply.

There's also entity-per-chunk-save-limit, which caps how many of each entity type save per chunk. That keeps a chunk full of dropped arrows or stray XP orbs from bloating the save file and dragging on load. Entity activation range is the last piece — it tiers ticking by distance, full tick within about 32 blocks and a reduced rate from 32 to 128, so lowering it cuts the CPU each distant entity costs. In modern Paper these live in config/paper-world-defaults.yml. One thing to skip: RAM-cleaner plugins. They fight the garbage collector instead of helping it, and they usually make things worse.

Pregenerate your world

Pregeneration is worth doing, but be honest about what it does. It's mainly a CPU and disk win, because generating new terrain is the most CPU-intensive thing the server does and it runs on the main thread. The memory benefit is indirect: when the world is already built, the server stops generating chunks live while players explore, and that keeps memory steadier during play.

Use Chunky — it's a plugin for Spigot and Paper and a mod for Fabric, Forge, and NeoForge. Set a center and radius and let it run while players are offline:

/chunky center 0 0
/chunky radius 10000
/chunky start

The part that actually bounds your memory is pairing this with a world border, either through ChunkyBorder or the vanilla one. Once players can only ever reach pregenerated chunks, you've capped the total number of chunks the server can ever be asked to load, which keeps both disk and memory predictable instead of sprawling every time someone walks in a straight line for an hour. Do it for the overworld, the nether, and the end, since exploration in any of the three can run the count up.

Trim unused plugins and mods

Every plugin you remove frees memory and CPU outright, so audit the list regularly and delete anything that's installed but unused. A plugin you're not actually using is pure overhead with nothing to show for it.

Where a plugin earns its keep but runs heavy, look for a lighter alternative that does the same job — not all of them are optimized equally, and swapping one out can cut a real chunk of memory. For anything database-heavy, point it at an external database instead of flat files so that data isn't sitting in your process. And lean on Spark again here rather than pulling plugins at random; it'll tell you which one is the actual hog. Keep an eye out for the ones whose memory creeps up over a long uptime and only settles after a restart — those are the leakers.

Set the heap correctly (and stop overallocating)

Set -Xms equal to -Xmx. That's Aikar's guidance, and it tells the JVM to claim its full heap up front instead of growing into it mid-session. Leave the OS a buffer of roughly 1 to 1.5GB rather than handing the whole box to the server.

Here's the counterintuitive part: more RAM is not better once your world comfortably fits. A bigger heap means the garbage collector has more memory to scan on every pass, so the pauses can get longer, not shorter. The rule of thumb is to allocate about 1 to 2GB above your steady-state usage, not the maximum the machine has lying around. Aikar's flags exist to tune G1GC for Minecraft's constant churn of short-lived allocations, and -XX:+AlwaysPreTouch makes the OS hand over the requested RAM at startup so there's no mid-session stall when the heap first fills. On Java 21 and up, ZGC is a solid alternative that keeps pauses tiny even on the large heaps modded packs need.

And diagnose before you upgrade. If TPS is dropping while memory sits far from full, the bottleneck is your CPU or one laggy chunk or entity, and more RAM won't touch it.

Why leaner memory is an uptime story

Right-sizing memory isn't about a smaller bill. It buys you stable TPS and reliable uptime, and that's what keeps players around. A server that stutters or drops offline bleeds the exact people who'd otherwise stick around and keep it active.

That matters here because the active, smooth-running communities are the ones that climb the monthly vote rankings — how server rankings work walks through the votes-per-month mechanism, and it's the players who keep coming back who cast those votes. The memory-heavy genres feel this most: a busy Skyblock island server or a modded pack will get more out of this tuning than a quiet vanilla world ever would, so if you're running either of those, it's worth a full pass.

FAQ

How do I read Spark's memory output to find the problem?

Run /spark profiler for a CPU and tick profile, or check the memory section of a Spark report for heap usage over time. The numbers you care about are steady-state heap (where memory settles between garbage collections) and how high it spikes during play. If the floor keeps creeping up restart after restart, something is leaking. If it's flat but high, you're holding too many chunks or entities — that points you at distance and entity settings rather than the JVM flags.

What heap size should I give a server for its player count?

There's no clean per-player number because chunks and entities dominate, not people. The honest method is to run the server under a normal load, read the steady-state heap from Spark, and set -Xmx about 1 to 2GB above that. A small vanilla survival server for a dozen friends often sits happy at 4 to 6GB; a busy modded pack can want 8GB or more. Start from measured usage, not a round number you saw in a guide.

Will lowering view-distance make the game look worse for players?

Less than owners expect. A player's own client render distance still draws the far horizon — your server's view-distance only governs how far it sends real chunk data. Drop it to 6 to 8 and most players won't notice anything beyond a slightly closer fog line on weaker setups. Simulation-distance is the one to be careful with, since it controls how far things actually tick; pull it too low and distant farms or redstone stop running for players standing outside the radius.

Where do I actually change these settings on a Paper server?

View-distance and simulation-distance live in server.properties at the server root, and Paper can also override them per-world. The entity controls — despawn ranges, per-player-mob-spawns, entity-per-chunk-save-limit, and activation range — are in config/paper-world-defaults.yml, with per-world overrides in each world's paper-world.yml. Heap flags like -Xms and -Xmx go in your startup script or panel's JVM arguments, not in any config file.