A block breaks, comes back, and then breaks again. The chat says “lag.” Someone suggests restarting. Someone else suggests 32 GB of RAM.
Both might be getting ahead of themselves. First, find out what is actually slow. It takes a little more effort than guessing, but you only have to fix the problem you have.
Ask what is slow, and who can see it.
Mobs moving slowly for everyone points you toward the server. One player waiting on every interaction calls for a connection check too. A picture that stutters when you turn the camera needs a look at the client. These are clues, so check the numbers while it happens.
Minecraft Java EditionThree different problems get called “lag”
Get two players in the same place and compare what happens. Is the whole game running behind, or is one person's screen struggling to draw it? The answer changes what you should investigate.
| Check | What it measures | Where to look next |
|---|---|---|
| TPS and MSPT | How quickly the server processes the game | Server workload, plugins, entities |
| Ping | Connection round-trip time | Connection quality and server location |
| FPS | Frames drawn on the player’s device | Shaders, render distance, device load |
20 TPS is good. It is not the whole story.
At the normal tick rate, Minecraft aims for 20 ticks per second. That leaves 50 milliseconds for each tick. MSPT tells you how long the work takes; sustained ticks above that budget mean the server falls behind.
A server at 15 MSPT and one at 45 MSPT can both report 20 TPS. The second has much less room for extra work. Look at spikes as well as averages, especially if players describe occasional freezes.
With a compatible server installation of spark and the right permissions, check the tick readings below. Leave off the slash when using the hosting console.
/spark tpsCatch the server in the act
Check whether your server software already includes spark before installing it. Then capture a short profile while the problem is happening. Two minutes is a useful first sample. If a profile is already running, check its status instead of starting another.
/spark profiler start --timeout 120- Reproduce the slowdown
Keep the usual players online. Note whether they are exploring, using a farm or visiting a particular base.
- Open the report
Expand the expensive branches. A broad parent entry can include lots of smaller jobs, so do not blame it just because it has the biggest number.
- Save the context
Keep the report link, time and relevant logs. Review the report before sharing it publicly, since it may include server details.
Try one change you can undo
If new terrain is the trigger, compare exploring with a session around existing bases. If a machine or farm stands out in the profile, try stopping it in a test copy. Don't start by deleting entities or removing content mods from the live world.
View distance changes the world data sent to players. Simulation distance changes how far away entities are updated. Lower settings can reduce work, but they also change the game. Write down the old values and make a modest adjustment.
Change ten settings together and you get a new mystery: which one helped? Keep the experiments small.
Buy the upgrade the evidence points to
Check memory usage and the logs around a crash. Java's memory graph normally rises and falls as garbage collection does its work. A sawtooth shape alone is not a reason to upgrade.
If memory is under sustained pressure, more room may help. If memory has room but ticks take too long, investigate the workload and CPU limits. An overall CPU percentage can hide a busy main thread, so keep the profile in the conversation.
When you ask for help, include the software and game version, pack or plugin list, when it happened and the profile link. “It lags when three of us fly into new chunks” gives support something useful to follow.
Sources & useful links
The technical details behind this guide, if you want to dig further.
Keep reading
Sculk Hosting
Stuck on your own setup?
Send us the game version and what happens when you try. A log or error message helps.