Fixing Minecraft lag tells you to stop guessing and profile with spark. This guide is the part after that: you've run the profiler, you have a link to a report, and now a wall of nested method names is staring back at you. Here's how to read it and walk away knowing exactly what's eating your tick.
| At a glance | |
|---|---|
| You need | spark installed from the Plugins page (needs a plugin-capable server — Purpur, Paper, Spigot family) |
| Plan | Any — profiling works fine on the free plan |
| Prerequisite | Fixing Minecraft lag for which lag you actually have |
First, the quick reads
Before the full profiler, spark has two commands that answer "is it even the server?" in seconds. Run them in the Console or in-game:
| Command | What it tells you |
|---|---|
/spark tps |
Current TPS (ticks per second — 20 is healthy) and MSPT (milliseconds per tick), plus CPU. If TPS is 20 and MSPT is low, the server is fine and your lag is client-side or ping |
/spark health |
A broader snapshot — memory use, garbage-collection pauses, disk. Good for spotting a memory problem masquerading as lag |
A tick is one heartbeat of the server; it aims for 20 per second, so it has 50 ms to do everything before it falls behind. When MSPT creeps above 50, TPS drops below 20 and the world visibly slows. That 50 ms budget is the number everything below is measured against.
Running the profiler
/spark tps says whether you're slow; the profiler says why. The idea is simple: start it, let the lag happen for a minute or two, stop it, and spark hands you a shareable online report.
/spark profilerStart it, reproduce the lag (or just wait if it's constant), then stop it. spark uploads the result and prints a link you open in a browser.
⚠️ Heads up: The exact profiler flags and subcommands (timeouts, thread selection,
start/stopvs--stop) have changed between spark versions. Don't memorize a flag off an old video — run/spark profilerand read what your build prints, or check the current reference at spark.lucko.me/docs.
Reading the report: the call tree
Open the link and you'll see the sampler — a tree of method calls, each with a percentage. This is a call tree: spark took thousands of snapshots of what the server was doing, and the tree shows where the time went, most-expensive branches first.
Read it like this:
- Start at the top and find the server thread. The report separates threads; the one that matters for TPS is the main server thread (labeled as the server/main tick thread). Client-side or unrelated threads don't cost you ticks.
- Follow the biggest percentages down. Open the widest branch, then the widest branch inside it, and keep going. You're drilling toward the specific method that's actually doing the work — the deeper you go, the more precise the answer.
- Watch for a package name you recognize. Somewhere down the branch you'll hit a name that isn't vanilla Minecraft — a plugin's package (
com.example.plugin…), a world-gen routine, an entity-tick method. That's your culprit.
What "X% of tick" means
Every frame in the tree shows a percentage — say "42%". That is the share of the sampled time that this method (and everything it called) was on the stack. It is not 42% of one tick; it's 42% of the whole profiling window spent in that code path. A branch sitting at 40%+ is doing a lot of your server's work, so that's where fixing something buys you the most back.
🎯 Good to know: Percentages are relative to what the server was doing, not to a fixed budget. On an idle server the biggest branch might still be tiny in real terms. Cross-check with MSPT from
/spark tps— high percentage and high MSPT together is what points at a real problem.
The culprit patterns you'll recognize
After a few reports the same shapes turn up. Here's what a fat branch usually means:
| What dominates the tree | Usually means | First move |
|---|---|---|
| An entity / mob tick method | Too many mobs, or heavy AI/pathfinding (mob farms, big herds) | Cap mob counts, thin out farms; lower simulation-distance |
| Chunk generation / world loading | Players exploring into fresh terrain | Pre-generate the world; lower view-distance |
| A specific plugin's package | That plugin is doing expensive work each tick | Check its config, update it, or replace it — see diagnosing plugin conflicts |
| Redstone / hopper / block-entity ticks | A big redstone contraption or hopper array | Optimize the build; some forks (Purpur) have hopper-tuning options |
Garbage collection high in /spark health |
Memory pressure, not CPU work | Confirm with Out of memory — don't tune the wrong thing |
The value of the report is that it turns "the server is laggy" into "this named thing is spending this much time." You fix that and re-profile — instead of flipping settings at random and hoping.
Verify your fix
Make one change, restart, and run /spark tps again with the same load. Better MSPT and TPS closer to 20 means it worked. For a real before/after, profile again and confirm the branch that used to dominate has shrunk. One change at a time, always — so you know which one helped.
Troubleshooting
/sparkdoes nothing — spark isn't installed or didn't load. Install it from the Plugins page, restart, and check it appears in/pluginsgreen.- The report link won't open — it's hosted online; make sure you copied the full URL from the console. spark uploads the data, so the link is the whole point.
- The tree is all vanilla Minecraft names — sometimes there's no single villain: the server is simply doing more than 2.5 GB of shared RAM can handle. That's the honest limit from the performance guide, not a bug.
- Anything about profiler flags or newer features — check spark.lucko.me/docs; the commands drift, the report-reading skill above doesn't.