How to Reduce RAM Usage on Your Minecraft Server

What Consumes RAM on a Minecraft Server

Before you start cutting RAM usage, you need to understand where it goes. A Minecraft server's memory footprint is composed of several categories, each with different optimization strategies:

• Loaded chunks, Each loaded chunk consumes roughly 10-20 KB of RAM depending on content. A server with a view distance of 10 and 50 players can easily have 30,000+ chunks loaded, consuming 300-600 MB just for terrain data. This is typically the largest memory consumer.
• Entities, Every mob, dropped item, item frame, armor stand, and vehicle is a Java object in memory. A chunk with 100 entities uses significantly more RAM than an empty one. Mob farms and animal pens are the usual offenders.
• Plugin caches, Plugins store data in memory for fast access. CoreProtect keeps a rolling buffer of recent block changes. Dynmap renders tiles and caches them. Economy plugins cache player balances. Chat plugins cache message history. Individually these are small, but a server running 30-40 plugins can easily accumulate 500 MB+ of plugin-held data.
• Java overhead, The JVM itself uses memory for class metadata, thread stacks, JIT-compiled code, garbage collection metadata, and internal buffers. This baseline is typically 200-400 MB regardless of server activity.
• World data, Player data files, scoreboard data, advancement tracking, and statistics all live in memory while the server runs.

Paper Config Settings That Reduce RAM

If you run Paper (and you should), several configuration options directly reduce memory consumption:

Spawn Limits

In bukkit.yml, the spawn limits control the maximum number of mobs per world:

spawn-limits:
  monsters: 50      # default 70
  animals: 8        # default 10
  water-animals: 3  # default 5
  water-ambient: 10 # default 20
  ambient: 1        # default 15

Lower values mean fewer entities in the world, which directly reduces RAM and improves TPS. The defaults are tuned for vanilla gameplay feel, but most players do not notice a reduction from 70 to 50 monsters. Start conservative and lower further if needed.

Simulation Distance

In server.properties or Paper config, the simulation distance controls how far from each player entities are ticked. Reducing this from the default 10 to 5-6 means fewer chunks are fully loaded with active entities, saving significant RAM:

simulation-distance=5

You can keep the view distance higher (7-10) so players still see terrain in the distance, but only the nearby chunks consume full RAM with active entities.

Unloading Configuration

Paper has options to control when chunks are unloaded from memory. The delay-chunk-unloads-by setting in paper-world-defaults.yml controls how long an empty chunk stays loaded after the last player leaves its area. The default is 10 seconds, which is reasonable. Setting it lower (5 seconds) frees RAM faster but may cause more I/O if players repeatedly move back and forth across chunk boundaries.

Reducing Loaded Worlds

If you use Multiverse or a similar multi-world plugin, each loaded world consumes RAM even if no players are in it. By default, Multiverse keeps the spawn chunks of every world loaded at all times. Disable this for worlds that are not constantly in use:

# In Multiverse config for each world
/mv modify set keepSpawnInMemory false world_nether
/mv modify set keepSpawnInMemory false world_the_end
/mv modify set keepSpawnInMemory false creative

A nether world with its spawn chunks loaded but no players in it wastes roughly 50-100 MB of RAM. On servers with 5+ worlds, this adds up. Only keep spawn loaded for worlds where players actually spawn (typically the overworld).

Plugin Audit, Finding Memory-Hungry Plugins

Some plugins consume disproportionate amounts of RAM. Common offenders:

• CoreProtect, Keeps a configurable rolling cache of recent block changes in memory. Reduce the cache size in config if you do not need instant lookups for old data. The max-pool-size and in-memory queue settings can be tuned down.
• Dynmap, Renders map tiles and caches them. A large world with Dynmap can consume 1-2 GB of RAM. Consider switching to Bluemap, which is more memory-efficient, or reducing the render distance and resolution.
• Citizens (NPC plugin), Each NPC with complex AI, pathfinding, and skins is a full entity in memory. Hundreds of NPCs add up. Use simple NPCs where possible and limit total count.
• Logging plugins, Plugins that log extensive data (block logs, chat logs, command logs) to in-memory buffers before flushing to disk can accumulate significant memory usage on busy servers.

To identify which plugins use the most memory, use Spark's heap inspection:

/spark heapsummary

This generates a report showing the largest object types in memory. Look for plugin-specific classes that appear with high counts or large total sizes.

JVM Flags for Memory Efficiency

The Java Virtual Machine flags you use to start your server have a significant impact on memory behavior. The widely recommended Aikar's flags are the gold standard for Minecraft:

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled   -XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions   -XX:+DisableExplicitGC -XX:+AlwaysPreTouch -XX:G1NewSizePercent=30   -XX:G1MaxNewSizePercent=40 -XX:G1HeapRegionSize=8M   -XX:G1ReservePercent=20 -XX:G1MixedGCCountTarget=4   -XX:InitiatingHeapOccupancyPercent=15   -XX:G1MixedGCLiveThresholdPercent=90   -XX:G1RSetUpdatingPauseTimePercent=5   -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem   -XX:MaxTenuringThreshold=1 -jar paper.jar --nogui

Why Xms Should Equal Xmx

Setting -Xms (initial heap) equal to -Xmx (maximum heap) is critical for Minecraft. When Xms is lower than Xmx, the JVM starts with a small heap and grows it on demand. Each resize triggers a full garbage collection pause, causing a lag spike. By starting with the full allocation, you avoid resize-triggered GC entirely. The memory is reserved at startup regardless, setting Xms lower does not "save" RAM at the OS level in any meaningful way.

G1GC Tuning

The G1 garbage collector (G1GC) is recommended for Minecraft because it targets consistent pause times rather than maximum throughput. The Aikar flags tune G1GC to aggressively collect short-lived objects (which Minecraft generates in enormous quantities every tick) while avoiding long pauses. Do not use ZGC or Shenandoah for Minecraft, they are designed for different workloads and typically perform worse for game servers.

Do Not Over-Allocate RAM

This is counterintuitive, but giving your server too much RAM can actually make performance worse. When you allocate 16 GB to a server that only uses 4 GB, the garbage collector has to scan 16 GB of heap space to find garbage. GC pauses scale with heap size, not with the amount of garbage. A 16 GB heap can have GC pauses of 200-500 ms, while a 6 GB heap might pause for only 50-100 ms.

Allocate what you need, plus a reasonable buffer:

Server Size	Typical Usage	Recommended Allocation
1-10 players, few plugins	1-2 GB	3-4 GB
10-30 players, moderate plugins	2-4 GB	5-6 GB
30-60 players, many plugins	4-6 GB	7-8 GB
60-100 players, heavy plugins	6-10 GB	10-12 GB
100+ players / network	Varies widely	Profile and allocate per server

Monitoring with Spark

Use Spark to monitor RAM usage in real time:

# Quick health check (TPS, RAM, CPU)
/spark health

# Detailed heap summary
/spark heapsummary

# Full GC analysis
/spark gc

The /spark health command shows current heap usage as a percentage. If your server consistently uses less than 50% of allocated RAM, you are over-allocated. If it regularly exceeds 85%, you either need more RAM or need to optimize further.

The GC report shows how often garbage collection runs and how long each pause takes. If you see pauses over 100 ms regularly, your heap is too large or your GC flags need tuning.

When to Upgrade vs Optimize

Optimization has limits. If you have already reduced view distance, lowered spawn limits, audited plugins, pre-generated chunks, and tuned your JVM flags, and the server still runs out of RAM, you genuinely need more RAM. Optimization is not a substitute for adequate hardware; it is about making the most of the hardware you have.

Signs you actually need more RAM (not just optimization):

• Spark shows consistent heap usage above 90% even after optimization.
• GC pauses are frequent and long despite proper flags.
• You have already removed non-essential plugins and reduced world count.
• Player count has grown beyond what your plan supports.

For a complete performance picture, combine RAM optimization with chunk loading optimization, profiling, and the settings from our full optimization guide.

Need better performance? Astroworld Hosting runs NVMe SSD, up to 96 GB RAM, and DDoS protection on every plan. See features , plans from €6.39/mo.