A profiler tells you where the tick's time went. The report looks intimidating because it is a full call tree, but you only ever need to read it one way: top down, following the biggest percentage.
Producing a useful profile
- Profile while it is bad
/spark profiler start, then wait for the problem. A profile of a healthy server tells you what a healthy server does, which is not what you asked. - Let it run for a few minutes
Thirty seconds catches a spike; five minutes catches a pattern. For an intermittent problem, longer is better.
- Stop it and open the link
/spark profiler stopgives you a web viewer. Nothing needs installing to read it.
The three shapes you will see
| Shape | Means |
|---|---|
| One plugin high in the tree | That plugin. Read the method name — it usually says what it was doing. |
| Entity or block-entity ticking dominating | A farm, a storage room, or too much loaded. Not a plugin problem. |
| Time spread thin across everything | You are simply at capacity for the plan. This is the case where a bigger plan is the honest answer. |
If the server is healthy, something still has to be the largest item in the tree — that is arithmetic, not a bug. Percentages matter when TPS is actually below 20. Optimising the top entry of a profile taken on a 20 TPS server is chasing nothing.
/spark health before profilingIt shows TPS, tick duration and memory in one screen. If tick duration is fine and memory is at the ceiling, your problem is garbage collection and a profile of the tick will not show it.
About Timings
Older guides tell you to use /timings. Paper has moved away from it in favour of spark, and on recent versions the command may not exist at all. If a guide leads with Timings, check its date before following the rest of it.