Minecraft Server Settings for Maximum Performance

The Quest for 20 TPS

Every Minecraft server owner shares the same goal: a smooth, lag-free experience at a consistent 20 TPS (ticks per second). But achieving this isn't just about throwing more RAM at the problem. In fact, over-allocating RAM is one of the most common mistakes that actually makes performance worse.

I've spent a lot of time tweaking these settings across dozens of servers, and I want to walk through every layer of Minecraft server optimisation – from the Java runtime to game-specific configs – with practical recommendations tested on real servers running modern AMD Ryzen hardware.

Layer 1: Java Version and JVM Flags

Your server's performance starts before Minecraft even loads – at the Java Virtual Machine level.

Use Java 21 or Later

Java 21 LTS introduced significant improvements to the G1 garbage collector, including better region management and reduced pause times. If you're running Minecraft 26.1+, you'll need Java 25, which brings even further improvements. Always use the latest supported Java version for your Minecraft version.

Aikar's Flags

Aikar's flags remain the recommended JVM configuration for Minecraft servers in 2026. They optimise the G1 garbage collector specifically for Minecraft's memory allocation patterns – and from what I've seen on our servers, the difference is night and day compared to default flags.

For servers with 12 GB RAM or less:

-Xms{RAM}M -Xmx{RAM}M -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:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true

For servers with more than 12 GB RAM, you need to adjust five flags (not just two – I see this mistake constantly):

-XX:G1NewSizePercent=40
-XX:G1MaxNewSizePercent=50
-XX:G1HeapRegionSize=16M
-XX:G1ReservePercent=15
-XX:InitiatingHeapOccupancyPercent=20

The larger heap means G1 needs bigger regions and different thresholds to handle garbage collection efficiently. Miss any of these and you'll end up with longer GC pauses than necessary.

A note on Java 25: These flags were tuned for Java 21. Minecraft 26.1+ requires Java 25 – keep an eye on PaperMC's docs for updated flag recommendations. The G1 collector has changed enough between versions that some of these values may need revisiting.

The Golden Rule: -Xms Equals -Xmx

Always set your minimum heap (-Xms) equal to your maximum heap (-Xmx). This prevents Java from wasting CPU cycles resizing the heap during gameplay. When these values differ, you get unpredictable GC behaviour and lag spikes as Java expands and contracts the heap.

Do Not Over-Allocate

This is counterintuitive, but giving your server too much RAM actually hurts performance. When the G1 garbage collector runs, it must scan the entire heap. A 20 GB heap takes significantly longer to scan than an 8 GB heap, even if most of that 20 GB is empty.

The rule of thumb: allocate 1–2 GB more than your server's steady-state memory usage. Monitor your actual usage with Spark or the /memory command and adjust accordingly.

Layer 2: Server Software Choice

Your choice of server software has a massive impact on performance.

Paper Over Spigot (Always)

There's virtually no reason to run Spigot over Paper in 2026. Paper includes every Spigot optimisation plus dozens of its own – async chunk loading, optimised entity ticking, faster world saving, improved hopper performance, and better mob pathfinding algorithms. Switching from Spigot to Paper typically improves TPS by 20–50% with zero configuration changes. That's not a typo.

Purpur for Extra Performance

Purpur builds on Paper and adds further performance tweaks and configuration options. If you want even more control over entity behaviour, mob spawning, and game mechanics, Purpur is worth considering. I'd recommend it for anyone comfortable with a few more config files.

Layer 3: server.properties

The server.properties file contains some of the most impactful performance settings. This is where the real performance gains hide.

View Distance

view-distance=6

This is the single most impactful performance setting. It controls how many chunks around each player are kept loaded. Each additional chunk is a square, so increasing from 6 to 10 nearly triples the number of loaded chunks per player.

I recommend 6 for most servers. Increase to 8 only if you have RAM and CPU headroom. Players can still see further using client-side render distance – most won't even notice.

Simulation Distance

simulation-distance=4

Controls how many chunks around each player have active entity processing (mob AI, redstone, crop growth, etc.). This is separate from view distance – chunks beyond simulation distance are visible but "frozen."

4 is the sweet spot for most servers. It keeps the gameplay experience largely intact while dramatically reducing entity processing load.

Network Compression

network-compression-threshold=256

Packets smaller than this threshold (in bytes) are sent uncompressed. Higher values reduce CPU usage from compression at the cost of slightly more bandwidth. 256 works for most servers. Bump to 512 if you've got bandwidth to spare and want to shave off a bit of CPU load.

Entity Broadcast Range

entity-broadcast-range-percentage=80

The default here is 100, meaning entities are sent to players across the full view distance. Dropping it to 80 means entities beyond 80% of the view distance aren't transmitted – reducing bandwidth and client-side rendering load. 80 is the recommended optimisation value, and players rarely notice the difference.

Layer 4: Paper Configuration

Paper provides additional configuration files with powerful performance settings.

paper-world-defaults.yml

chunks:
  auto-save-interval: default        # Delegates to bukkit.yml (usually 6000 ticks / 5 min)
  max-auto-save-chunks-per-tick: 24  # Spread saves across ticks

environment:
  optimize-explosions: true          # Default is false – set to true for a noticeable improvement
  treasure-maps:
    find-already-discovered:
      loot-tables: default
      villager-trade: true           # Prevents lag from repeated treasure map searches

tick-rates:
  mob-spawner: 2                     # Check spawners every 2 ticks instead of 1

A few notes on these: auto-save-interval: default delegates the save interval to your bukkit.yml setting, which is usually 6000 ticks (about 5 minutes). This is the cleanest way to handle it unless you have a specific reason to override. And optimize-explosions being false by default is one of those things that surprises people – trust me, flipping it to true makes a difference on any server where TNT or creepers are involved.

Entity Activation Range

One of Paper's most powerful performance features. Entities beyond certain distances from players have their AI simplified or paused entirely. Here are the Paper defaults:

entity-activation-range:
  animals: 32
  monsters: 32
  raiders: 48
  misc: 16
  water: 16
  villagers: 32
  flying-monsters: 32

These are the stock Paper values. If you're looking to squeeze out more performance, try lowering them:

entity-activation-range:
  animals: 16
  monsters: 24
  raiders: 48
  misc: 8
  water: 8
  villagers: 20
  flying-monsters: 24

Reducing these values means entities further from players use less CPU. Most players won't notice the difference unless they're specifically watching distant mob behaviour. Start with the lower values and increase if players complain about mob farms or villager trading behaving oddly.

Layer 5: World Optimisation

Pre-generate Your World

New chunk generation is by far the most CPU-intensive task on a Minecraft server. Every time a player walks into uncharted territory, the server must generate terrain, place structures, populate biomes, and light the chunks. I've seen servers drop to single-digit TPS during exploration sprees.

Use the Chunky plugin to pre-generate your world:

/chunky world <worldname>
/worldborder set 10000
/chunky radius 5000
/chunky start

This process can take hours for large worlds but eliminates chunk generation lag during normal gameplay. Run it overnight or during off-peak hours.

Set a World Border

A world border prevents players from endlessly exploring and generating new chunks. It also helps control disk usage and backup sizes.

/worldborder center 0 0
/worldborder set 10000

For most servers, a 10,000-block radius (20,000 x 20,000 area) provides more than enough space.

Layer 6: Plugin and Mod Optimisation

Audit Your Plugins

Not all plugins are created equal. Some common ones are known performance problems:

• Dynmap is extremely RAM-hungry. Consider Squaremap or BlueMap instead – significantly lighter for what they do.
• EssentialsX is well-optimised overall, but EssentialsX Chat and EssentialsX Spawn can be replaced with lighter alternatives if you're counting milliseconds.
• Make sure WorldGuard is on the latest version. Older builds have known performance issues that have long since been fixed.

For a deeper look at plugin choices, check out our top Minecraft server plugins for 2026.

Use Spark to Profile

Install Spark and run regular profiles during peak player times:

/spark profiler start
# Wait 3-5 minutes during normal gameplay
/spark profiler stop

The resulting report shows exactly which plugins, entities, or tasks consume the most tick time. Focus your optimisation efforts on the top offenders – you'd be surprised how often a single poorly-written plugin is responsible for most of the lag.

Putting It All Together

Here's the checklist I run through on every new Minecraft server:

1. Use Paper (or Purpur) as your server software
2. Set Java 21+ with Aikar's flags – all of them, including the >12 GB adjustments if applicable
3. Set -Xms equal to -Xmx at your allocated RAM
4. view-distance=6 and simulation-distance=4
5. Pre-generate your world with Chunky
6. Set a world border
7. Configure Paper's entity activation ranges (lower than defaults if you can get away with it)
8. Install Spark and profile during peak times
9. Audit plugins for performance impact
10. Monitor TPS regularly and investigate any drops

With these optimisations in place, most servers will maintain a rock-solid 20 TPS even under moderate load. If you're still seeing dips after all of this, it's almost always a plugin issue – Spark will tell you which one.

For more detail on individual settings, check the server configuration guide or the troubleshooting guide if something's not behaving.