15 Tips to Optimize a Minecraft Server

Introduction

A Minecraft server that lags is almost never a hardware fatality: it's very often a default configuration that was never touched. Between the server.properties file generated on first install, the default values of Paper, Spigot or Bukkit, and plugins installed without ever being monitored, there's a huge gap between a server that runs "more or less" and a server that holds a solid pace with people connected. Here are 15 concrete tips, to apply one by one, to optimize a Vanilla, Paper, Spigot or modded server at serv-minecraft. Each setting is explained with the file involved and the value to change.

Tip 1: adjust view-distance and simulation-distance

These are the two settings that weigh the most on a server's CPU load. view-distance controls the number of chunks loaded and sent around each player, simulation-distance controls how far the world is actually simulated (mobs, redstone, crops). The default values (often 10) are comfortable but costly. On the serv-minecraft panel, open your server's Settings tab: the view-distance and simulation-distance fields can be changed directly, without going through a file editor.

• Small server between friends: 8 to 10 is plenty.
• Server with plugins and lots of people connected: drop to 6-8 if the TPS starts to sag.
• Technical modpack with lots of active machines: favor a low simulation-distance (5-6) over a low view-distance, to keep decent rendering without simulating too far.

Tip 2: clean up the other server.properties settings

Beyond the distances, a few lines in server.properties deserve a look:

• spawn-protection: pointless beyond a few blocks if you trust your community or have a dedicated protection plugin (WorldGuard, for instance).
• network-compression-threshold: too low a value compresses too many small packets and burns CPU for nothing; 256 is a good starting point.
• max-tick-time: don't disable it lightly, it's what triggers the watchdog when the server freezes abnormally.
• entity-broadcast-range-percentage: lowering this value limits the distance at which entities are synced to players, useful on a server with lots of mobs or mods.

Tip 3: tune paper-global.yml

On a Paper server, the global configuration lives in config/paper-global.yml (the config folder at the root of the server, visible from the panel's Files tab). This is where the settings that apply to the whole server, regardless of world, live:

• chunks section: automatic chunk save frequency, maximum number of chunks saved per tick.
• watchdog section: delay before a forced restart when the server freezes completely.
• collisions section: disabling collisions between identical entities can lighten a server with huge stacks of mobs.

Edit this file with the server stopped, then restart to apply the changes: unlike some plugins, Paper doesn't always reload its global configuration cleanly on the fly.

Tip 4: tune paper-world-defaults.yml per world

Next to the global file, config/paper-world-defaults.yml (and its per-world equivalent) holds the settings applied world by world: hopper behavior, natural spawn limits, entity handling. Two settings to watch first on a server lagging because of redstone and automatic sorting:

• hopper section: cooldown applied to full hoppers, disabling certain costly events tied to item movement.
• entities section: spawn limits and behavior of "spawner" entities (mob spawners).

These two files (global and per world) are complementary: the global one sets the server's framework, the per-world one fine-tunes it based on the actual use of each world (survival, creative, side world).

Tip 5: adjust spigot.yml

Whether you're running Spigot or Paper (which inherits Spigot's configuration), the spigot.yml file stays relevant for three settings with a direct impact on performance:

• entity-activation-range: the distance at which entities (animals, monsters, others) are actually active and processed by the server rather than put to sleep.
• mob-spawn-range: the radius around the player where mobs can spawn naturally, not to be confused with view-distance.
• merge-radius: the merge radius for dropped items and experience orbs, to avoid hundreds of separate entities doing the same job.

Carefully lowering these three values can win several TPS points on a server with lots of mobs, with no visible change for players.

Tip 6: adjust bukkit.yml

More modest but still useful, bukkit.yml notably controls:

• spawn-limits: the maximum number of monsters, animals, water animals and ambient mobs that can exist at once on the server.
• ticks-per (monster-spawns, animal-spawns): the frequency of natural spawn attempts; increasing it slightly reduces load without removing spawning.
• chunk-gc.period-in-ticks: the cleanup frequency for inactive chunks held in memory.

This file is edited with the server stopped, like the previous ones, from the panel's Files tab.

Tip 7: use Aikar's JVM flags

The choice of arguments passed to the Java virtual machine has a real impact on the micro-freezes caused by the garbage collector. The most recommended flag set in the server community is still the one known as "Aikar":

java -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 \
-jar server.jar nogui

Replace {RAM} with the same value for Xms and Xmx (allocating all the available RAM up front saves the server from having to ask for more along the way). On the serv-minecraft panel, these flags are already applied automatically depending on the plan: you have nothing to do, unless you manage a custom startup line yourself in expert mode.

Tip 8: pre-generate the world with Chunky

A world that generates "live" as players explore is a classic source of occasional lag: every newly generated chunk costs CPU right at the moment a player is moving forward. The Chunky plugin (Paper/Spigot) lets you pre-generate an entire area ahead of time, offline or under light load:

/chunky world world
/chunky radius 5000
/chunky center 0 0
/chunky start

Pre-generation can take a while depending on the chosen radius, but it runs in the background and can be paused (/chunky pause) then resumed (/chunky continue) without losing progress.

Tip 9: profile with Spark before optimizing blindly

Before changing settings at random, the good practice is to pinpoint exactly what's consuming the most server time. The Spark plugin (installable like any other plugin, in the plugins folder) provides a lightweight profiler:

/spark profiler start
/spark profiler stop
/spark tps
/spark health

The /spark profiler stop command generates a link to a detailed report, plugin by plugin and method by method, showing exactly where the computing time goes. It's the tool to reach for first before suspecting any particular plugin.

Tip 10: keep timings as a backup

On versions where Spark isn't installed, Spigot/Paper's historical timings system remains available as a last resort:

/timings on
/timings paste

It gives an older but still readable view of how time is split between plugins and internal server tasks. In practice, Spark is now the recommended first choice for its precision and readability, but timings stay useful if a particular plugin isn't yet compatible with Spark.

Tip 11: keep entities and hoppers under control

Hoppers are handy for automatic sorting, but every item transfer costs server time. A network of dozens of hoppers running continuously can, on its own, tank the TPS of an otherwise lightly populated server. A few habits to pick up:

• Limit the number of hoppers stacked vertically when a single one would have done the job.
• The hopper setting in paper-world-defaults.yml (tip 4) lets you add a cooldown when a hopper is full, to avoid unnecessary checks.
• On a modded world with heavy automation (factory-style), favor the mod's own transport machines rather than stacking vanilla hoppers.

Tip 12: clean up dropped items and useless entities

Items dropped on the ground (mob loot, harvests, explosions) and abandoned entities (empty minecarts, boats, forgotten armor stands) build up over time and end up weighing on the server. A periodic cleanup plugin (with a warning message before removal) is widely recommended on an active community server, on top of the merge-radius setting seen in tip 5.

Tip 13: watch out for risky plugins

Not all plugins are equal when it comes to performance. Before installing one, check:

• The date of the last update and the announced compatibility with your Minecraft version.
• Reviews and feedback on its CPU/RAM usage (looping area-scan plugins, permanent particle effects or poorly optimized anti-cheat plugins are classic culprits to watch).
• Duplicate features: two economy plugins or two anti-grief plugins overlapping each other burn resources for nothing and can conflict with one another.

For a plugin-oriented server, our page Minecraft plugins server details the plans suited to that kind of use.

Tip 14: choose the right amount of RAM based on mods and plugins

A lot of lag simply comes from a server that's undersized for what it's running. A few benchmarks:

• Vanilla or Paper with no (or very few) plugins: the Start plan (8 GB, €4.99/month) is plenty.
• Paper/Spigot with a real list of plugins (economy, protection, minigames, permissions): the Plugins plan (16 GB, €8.99/month) is built for that.
• Average modpack on Forge, Fabric or NeoForge: the Modded plan (24 GB, €15.99/month), see our guide creating a modded Minecraft server.
• Large, heavily loaded modpack: the Modpack plan (32 GB, €21.99/month) gives the needed headroom.

All plans and their details are on the plans page, with the option to switch plans from the panel if your server grows.

Tip 15: enable automatic backups

This isn't a performance gain strictly speaking, but it's the tip that saves you from losing everything after a bad manipulation, a buggy plugin, or a redstone plugin issue that corrupts an area. The Backups option (€4.49/month) creates automatic restore points, manageable from the panel's Backups tab: manual creation on demand, one-click restore, and the ability to lock an important backup to keep it from being deleted automatically.

FAQ

Which tip should I start with if my server is already lagging?

Start by profiling with Spark (tip 9) before touching any configuration file: it saves you from guessing and wasting time on a setting that wasn't the real problem. After that, view-distance/simulation-distance (tip 1) and hoppers (tip 11) are the two most frequent causes.

Do these settings also work on a modded server (Forge/Fabric/NeoForge)?

Aikar's JVM flags (tip 7), pre-generation (tip 8) and the choice of RAM (tip 14) apply to any type of server. The paper-global.yml, paper-world-defaults.yml, spigot.yml and bukkit.yml files, on the other hand, are specific to Paper/Spigot and don't exist on a pure Forge or Fabric server.

Do I need to restart the server after every change?

For server.properties, paper-global.yml, paper-world-defaults.yml, spigot.yml and bukkit.yml, yes: these are files read at startup, so a full restart is needed to apply the changes.

How long does a pre-generation with Chunky take?

It depends on the chosen radius and the power allocated to the server: from a few minutes for a small area to several hours for a very wide radius. The task runs in the background and can be paused at any time.

Are these tips enough if my plan is too tight?

No: past a certain point, no setting replaces having sufficient resources. If the TPS stays low despite applying all these settings, that's the signal to move up to the next plan via the panel rather than keep hunting for a miracle setting.