Minecraft Admins: Measure with Spark, Fix Lag, or Choose Tuned Hosting

The fastest way to restore stable 20 TPS: switch to Paper or Purpur if you haven't already, profile with Spark to find the real bottleneck, apply Aikar's JVM flags with a heap where Xms equals Xmx, then trim view-distance, simulation-distance, and mob or hopper activity. Pregenerate chunks with Chunky and run on NVMe storage wherever possible. Do these in order, measuring after each one, and you'll usually find the culprit before you finish the list.

TL;DR:

• Switching to Paper or Purpur can deliver 20 to 50 percent TPS improvements even before additional tuning efforts begin.
• Using Aikar's JVM flags with Xms equal to Xmx and running on NVMe storage significantly reduces lag caused by heap resizing or slow disk loads.
• Lowering server view-distance to 6–8 and simulation-distance to 3–5 helps reduce real workload and prevents unnecessary entity processing.
• Pregenerating chunks with Chunky before players explore new regions prevents CPU-intensive terrain generation spikes during active gameplay.
• Regular profiling with Spark during lag events, combined with disabling nonessential plugins and monitoring CPU/memory/ disk pressure, is crucial for identifying and fixing the main causes of lag.

Table of Contents

• Quick Wins to Reduce Minecraft Server Lag Right Now
• How Do You Diagnose the Real Cause of Server Lag?
• Does Your Server JAR and Java Setup Matter?
• Which Server.Properties and Paper Settings Actually Help?
• What's Actually Causing Your Plugin and Entity Lag?
• How Do You Pregenerate Chunks to Stop Generation Spikes?
• What Hardware and Hosting Setup Do You Actually Need?
• How Often Should You Monitor and Maintain Your Server?
• What Admins Get Wrong About Performance Tuning
• Get Hosting Built for the Optimizations Above
• Sources
• FAQ

Quick Wins to Reduce Minecraft Server Lag Right Now

Before touching config files, run a fast triage pass. This won't solve chronic problems, but it stabilizes gameplay while you dig into the real diagnosis.

1. Run /tps and note the MSPT (milliseconds per tick) reading, not just the TPS number.
2. Start a quick Spark profile the moment lag hits, so you capture the actual event, not a calm server.
3. Drop view-distance to 6 and simulation-distance to 4, then watch how MSPT responds over the next few minutes.
4. Disable nonessential plugins during peak hours to see if the lag disappears, which points straight at a plugin issue.
5. Push backups and any scheduled restarts to off-peak hours. Backups competing with active gameplay for disk I/O is a classic, avoidable spike.
6. If lag correlates with players exploring new terrain, pregenerate that region and set a matching world border.

Pro Tip: Keep a simple log of every change you make with a timestamp. When TPS improves two hours later, you want to know which one setting actually did it, not guess between five.

How Do You Diagnose the Real Cause of Server Lag?

TPS (ticks per second) tells you how many times the server updates world state each second, with 20 as the healthy target. MSPT (milliseconds per tick) is usually the more useful number because it shows you the actual budget: the server has 50 milliseconds to finish everything in a tick before it starts falling behind. If MSPT creeps past 50, TPS drops, and players feel it as rubber-banding, delayed hits, or frozen mobs.

Start with these commands:

• /tps for a fast TPS snapshot across the last 1, 5, and 15 minutes.
• /spark profiler start to begin capturing, then /spark profiler stop once you've caught a representative lag window.
• /spark tps for a more detailed tick-time breakdown than the vanilla command gives you.
• /spark health for a quick read on CPU, memory, and disk pressure.

The trick is timing. A profile captured while the server is calm tells you nothing. Run the profiler right as the lag event starts, let it run through the worst of it, and stop it once things settle.

Spark turns that capture into a flame graph, which is the single most useful diagnostic tool available for Minecraft servers today. Spark replaced the old Timings system specifically because it shows method-level and plugin-level CPU attribution that Timings never could. Reading one is simpler than it looks: look for wide bars sitting directly under the main tick loop.

The workflow that actually works: reproduce the lag, profile it, identify the top two or three contributors by width, change exactly one of them, then profile again. Skipping straight to changing five settings at once is how admins end up with a "fixed" server they can't explain and can't reproduce if it breaks again.

Does Your Server JAR and Java Setup Matter?

Vanilla and Spigot are not built for scale, and the gap shows up immediately once you switch. Paper adds async chunk loading, tuned entity activation ranges, and dozens of tick-loop optimizations that Vanilla simply lacks. Purpur builds on Paper with even more configurable performance knobs. Guides to tracking real-world upgrades consistently report 20 to 50 percent TPS gains from moving to Paper or Purpur alone, before any other tuning happens. If you're still on Vanilla or Spigot, this is the highest-leverage, lowest-risk change on this entire list.

Java version matters too. Run the latest version your Minecraft release supports, and favor a recent LTS release for its garbage collection improvements.

On JVM flags:

• Use Aikar's flags as your starting point. They're tuned specifically for Minecraft's memory allocation pattern, not generic Java workloads.
• Set Xms equal to Xmx. A heap that resizes mid-session causes stutters exactly when you can least afford one.
• Don't over-allocate RAM "just in case." A larger heap means the garbage collector has more to scan, and that usually means longer, more noticeable pause spikes, not smoother performance.
• Heaps above 12 GB need extra care with G1GC region sizing; the default tuning starts to lose efficiency at that scale, so test rather than assume.

A typical Paper startup command looks like this, with [X] replaced by your heap size in gigabytes:

java -Xms[X]G -Xmx[X]G -XX:+UseG1GC -XX:+ParallelRefProcEnabled -XX:MaxGCPauseMillis=200 -jar paper.jar

Pro Tip: Change the JAR and the JVM flags in the same test window, then hold everything else steady for 24 hours before touching config files. That isolates the biggest gain first and stops you from misattributing it to something smaller later.

Which Server.Properties and Paper Settings Actually Help?

Two settings get confused constantly, and mixing them up wastes time. View-distance controls how far terrain renders for the client. Simulation-distance controls how far the server actually ticks entities, redstone, and block updates. Lowering simulation-distance cuts real server workload; lowering view-distance mostly just changes what players see.

Start conservative and adjust based on how your player base actually plays:

• view-distance: 6 to 8 is a reasonable starting range for most survival servers.
• simulation-distance: 3 to 5, tested and adjusted based on how spread out your players get.
• entity-activation-range (Paper config): tighten this so distant entities stop consuming AI cycles they don't need.
• max-entity-collisions: lower this to reduce the cost of large mob or item pileups.
• Per-chunk save limits and despawn ranges: Paper exposes both, and tightening despawn ranges reduces the number of items and mobs the server has to track long term.

Mob caps deserve their own attention. Every loaded chunk contributes to a per-world spawn cap, and dense farms or grinders can quietly consume most of that budget. Setting spawn-limits per category (monsters, animals, water, ambient) gives you finer control than a single global cap.

Network compression threshold trades CPU for bandwidth. A lower threshold compresses more packets, saving bandwidth at the cost of CPU cycles; a higher one does the reverse. Most servers do fine leaving it near default unless bandwidth is the bottleneck you profiled. And stagger autosave rather than letting every world save on the same tick. That single change alone removes a lot of the periodic, predictable "everyone lags at the same time" spikes players complain about.

What's Actually Causing Your Plugin and Entity Lag?

Entity-heavy systems are the most common source of persistent, not spiky, TPS loss. Hoppers, redstone clocks, mob farms, and villager trading halls show up constantly in flame graphs as top offenders, and unlike a plugin bug, players build more of them the more your economy grows.

1. Open your Spark profile and sort by CPU share. Any single plugin consistently above 15% is worth investigating on its own.
2. For hopper-heavy builds, slow hopper transfer rates or move item sorting to water-stream based designs where the design allows it.
3. Hunt for redstone or observer clocks running faster than the gameplay actually needs, and rate-limit or disable the ones left running from testing.
4. If villager trading halls are common on your server, cap trading hall density or the AI cost per villager per chunk becomes real over time.
5. When no single suspect stands out, bisect: disable half your plugins, measure, then narrow down from there. It's slower than a hunch, but it's reliable.

How Do You Pregenerate Chunks to Stop Generation Spikes?

Generating new terrain is the single most CPU-intensive task a server performs, heavier than almost anything else on this list. Every time a player walks into unexplored territory, the server has to calculate biomes, structures, and terrain features in real time, competing for the same CPU cycles as everyone else's gameplay. Pregeneration converts that cost into a cheap disk read done ahead of time instead of a CPU spike during play.

Chunky is the standard tool for this:

• Install it as a plugin or mod depending on your server type.
• Set a radius that covers your expected play area, not just your current one.
• Run it off-peak. Pregeneration is disk and CPU intensive, and running it during active play just relocates the lag instead of eliminating it.
• Monitor disk space as it runs. A large world border at high render distance can consume tens of gigabytes before you're done.

Set a world border matching your pregenerated radius immediately afterward, so players can't wander past it and trigger fresh generation anyway. Schedule your next backup after pregeneration finishes, not during it. NVMe storage cuts pregeneration time significantly compared to SATA SSDs or HDDs, and it keeps paying off during normal play every time a chunk loads from disk.

What Hardware and Hosting Setup Do You Actually Need?

Minecraft's main thread is single-threaded by design, so clock speed on a single core matters more than total core count. A CPU with a high boost clock will outperform a chip with twice the cores and a lower per-core speed, every time, for tick processing.

• RAM: roughly 4 to 6 GB for around 10 players, scaling to 10 to 12 GB for larger, plugin-heavy servers. More than that rarely helps and can hurt GC pause times.
• Storage: NVMe SSDs materially reduce chunk-load latency compared to SATA SSDs, and HDDs are a poor fit for any actively played world.
• Network: aim for 100 Mbps as an absolute minimum, with 1 Gbps preferred once you're running a larger population, since latency matters more than raw throughput here.
• Hosting type: shared hosting rarely gives you the dedicated CPU cycles Minecraft's main thread needs. A VPS or a dedicated node with guaranteed single-core performance is the more reliable path once you're past a small hobby server.

For a closer look at matching RAM and CPU choices to your expected player count, the server sizing breakdown walks through the math in more detail.

How Often Should You Monitor and Maintain Your Server?

Optimization isn't a one-time project. Profile during peak hours weekly and log the results somewhere you'll actually check, so a slow regression doesn't sneak past you over a few months.

• Test one change at a time, under load that resembles your real peak, and always have a rollback plan before you deploy.
• Schedule restarts roughly every 24 to 72 hours depending on how heavy your server runs, but treat that as memory hygiene, not a fix for an underlying tuning problem.
• Keep backups and any heavy scheduled tasks off-peak, and watch disk I/O specifically during those windows.
• Set alerts on MSPT thresholds, disk latency, swap usage, and CPU steal if you're on a virtualized host, since steal time is invisible until you're specifically watching for it.

Pro Tip: If MSPT creeps up gradually over weeks rather than spiking suddenly, suspect a slow entity leak, like a farm nobody's cleaning up, before you suspect hardware.

What Admins Get Wrong About Performance Tuning

Optimization is iterative, not a checklist you complete once. You measure, change one thing, and accept that some tuning decisions trade a little gameplay flexibility for stability, and that's a fair trade more often than players think. The mistake I see most is admins tuning distances and flags indefinitely on hardware that's simply undersized for their population, when the actual fix is splitting game modes across separate instances or adding a proxy layer. Tuning has a ceiling. Know where yours is, and tell your community honestly when a restart or a distance change is coming, because unexplained lag erodes trust faster than a scheduled five-minute restart ever will.

— Ihor

Get Hosting Built for the Optimizations Above

Every fix in this guide assumes you have the hardware to support it, and that's where a lot of admins hit a wall running Minecraft on hosting built for a static website. Some hosting providers run game server nodes on NVMe storage and high single-core-performance CPUs, the combination recommended for stable 20 TPS.

Its Minecraft game server plans come with free migration, so moving an existing world over doesn't mean rebuilding your setup from scratch, and daily backups run automatically off-peak instead of competing with your players for disk I/O. If your current server has outgrown shared or budget hosting and you're chasing the single-core clock speed this article keeps pointing back to, the VPS hosting lineup gives you dedicated resources without jumping straight to a full dedicated box. For larger communities running multiple worlds or heavy plugin stacks, the dedicated server options pair high-boost-clock CPUs with NVMe storage built for exactly this kind of sustained load. Check current plan details and get a server sized to your player count.

Sources

• Spark - spark-vs-others
• Mc-servers
• Low

FAQ

How Can I Optimize My Minecraft Server for Performance?

Switch to Paper or Purpur, apply Aikar's JVM flags with Xms set equal to Xmx, and profile with Spark before making further changes. From there, lower simulation-distance, tighten mob and hopper activity, and pregenerate chunks with Chunky to remove generation spikes.

What Is Port 25565 Used For?

The default TCP port Minecraft servers use to accept client connections has no direct effect on TPS or tick performance; it's purely a networking setting, so changing it won't fix lag, only connectivity or firewall issues.

Is 1 GB RAM Enough for a Minecraft Server?

No. Even a small, mostly empty vanilla server struggles below 2 to 3 GB, and any server with plugins or more than a couple of players needs closer to 4 to 6 GB. A managed VPS hosting plan with dedicated RAM avoids the swapping and crashes that undersized memory causes.

Why Is Minecraft So Poorly Optimized by Default?

Vanilla Minecraft runs its world simulation on a single main thread, and it wasn't originally built with large multiplayer communities in mind. Server software like Paper patches around this with async chunk loading and smarter entity handling, which is why the JAR you choose changes performance so dramatically.

Do I Need a Dedicated Server or Is VPS Hosting Enough?

A VPS works well for most communities up to a few dozen concurrent players, provided it guarantees dedicated CPU cycles rather than shared ones. Larger servers running multiple worlds or heavy plugin stacks generally see more consistent MSPT on a dedicated server with a high single-core clock speed.

Recommended

• US Minecraft Server Sizing: 4–6 GB RAM & Fast CPU for 10–20 Players