Short answer
Vanilla gives you no profiler plugin, so measure with /tps and the built-in debug report, then lower view and simulation distance, clear entity pile-ups and kill runaway redstone. If those are clean and TPS is still low, the honest options are a fork or more hardware.
Vanilla servers lag for the same reasons every server does, and diagnosing them is harder because vanilla ships no profiler and almost no configuration. What it does ship is a tick counter and a debug report, which together are enough to find most causes without installing anything.
This guide uses only what vanilla has: /tps, /debug start and /debug stop, and the three settings in server.properties that move the needle. Where vanilla runs out of options, it says so.
Before you start
- Operator access, level 2 or higher, for the debug commands
- Access to
server.propertiesand the ability to restart - Ten minutes of measurement
1. Establish whether the server is behind at all
Run /tps. Twenty is the target and the ceiling. Below 18 consistently, players will feel it; brief dips during heavy moments are normal. If it reads 20.0 while players stutter, the server is keeping up and the problem is their connection or their client.
Ask which players are affected and when. Everyone feeling it at the same moment points at the server; one person feeling it alone points at their network.
/tps2. Capture a debug report for the lag period
Vanilla can record what the server is doing: start the debug report, let the server run the way it runs when players complain, and stop it. The result names the tasks taking the most time, which is the same information a profiler plugin gives you.
Keep it short. A report over a normal session rather than a problem session tells you what the server usually does, which is not the same thing as what is wrong.
/debug start
# wait for the lag, with players on
/debug stop3. Lower view distance and simulation distance
These are the only two vanilla settings with a large effect on tick time, and both default to 10 with a range of 3 to 32. View distance decides how many chunks are loaded and generated; simulation distance decides how far away entities keep moving. Together they multiply everything the server does per tick.
On a small server, 6 for both is the single biggest change available. The cost is a shorter view and mobs that stop moving sooner, which fog and client-side render settings mostly hide.
view-distance=6
simulation-distance=64. Clear entity pile-ups and tame redstone
Entities tick every second whether anyone is looking or not. A breeding pen of hundreds of animals, a spawner nobody has visited in a month, and the item drops a broken farm left behind all cost the same tick time as the village you built, and none of it is visible.
Walk your farms and clear them. Use commands to count what is there: /count needs no mod and /execute as @e[type=minecraft:cow] run say hi on a large animal pen is a fast way to see how bad it is. For redstone, clocks and observer chains built to run forever are the other permanent cost; throttle them or unload the area.
/execute as @e[type=!player] run data get entity @s UUID
/forceload remove ~ ~5. Decide honestly between tuning, software and hardware
When the report shows heavy chunk work, a vanilla server is at its limit: it loads and generates chunks on the main thread while players wait, and there is no setting to change that. Pre-generating the map offline helps, and so does a world border to stop players walking past it.
If the report is flat and TPS is still low, the server is doing more work than one core can hold: too many players, too much automation, too much explored world. At that point the real options are switching to Paper, which handles entities and chunk loading far better, or more hardware. Neither should be chosen from frustration; both are reasonable, and the measurements tell you which one you need.
Good to know
- Vanilla has no equivalent of a per-tick profiler plugin, so the debug report is the closest thing it has. It is enough for the causes above and unhelpful for plugin problems, because vanilla has no plugins.
/tpsmeasures the last 1, 5 and 15 minutes. Read the 15-minute figure before changing anything, or you will act on a spike.- A restart that makes lag disappear for an hour has not fixed it. It has cleared a pile-up, and pile-ups come back.
- The general lag guide covers the same diagnosis with the profiler tools a fork gives you.
Common questions
How do I check my vanilla server performance?
Run /tps in game and read the 15-minute average: 20.0 is the target, under 18 sustained is what players feel. For more detail, /debug start and /debug stop produce a report of what the server spent its time on.
Why is vanilla so much worse than Paper?
Because Paper was written to do the same tick work with less overhead, especially for entities and chunk loading. On a busy world that is a large gap; on a small server with few players it is small. Vanilla vs Paper sets out the trade.
What is the best view distance for a vanilla server?
Six to eight on one core. Both view and simulation distance default to 10 and range from 3 to 32, and both multiply tick work. Lower simulation distance first if the problem is mobs, and keep it at or below view distance.
Can I install a profiler on a vanilla server?
Not the plugin kind: vanilla implements no plugin API. Fabric has server-side mods including profilers, but that turns your vanilla server into a modded one. For a stock server, the built-in debug report is the tool.
Sources
Official documentation this guide was checked against.
Rather not run this on your own machine? PufferHost gives every player a free Minecraft server with 3 GB of RAM and 10 slots. Create a free server.