Direct answer

Start with the thread doing the affected tick work, then expand the largest relevant sampled branches. Each percentage shows work observed in that profile, not a guaranteed exact cost for every tick.

How to check it

  1. Generate a report during lag with /spark profiler start --timeout 180 and open the spark viewer.
  2. Find the Paper server tick thread in the thread list. In Folia, inspect the affected region tick threads instead; a proxy may have no comparable world tick thread.
  3. Expand the heavy branches from general server tick methods toward a plugin package, entity logic, chunk operations or other leaf frames.
  4. Differentiate your own plugin code from framework overhead. A common Minecraft method may be invoked by many plugins; trace the parent frames.
  5. Use the timeline to focus on the period of the actual problem, and compare a second capture after a controlled change.

What to change

  • When plugin methods dominate, check plugin tasks, entity scans, database operations and configured work intervals.
  • When world logic dominates, locate the corresponding farm, mob, redstone or chunk activity before changing server-wide knobs.
  • When much time appears outside the expected tick thread, inspect other threads and health/GC metrics rather than forcing a tick-thread explanation.

Software and version notes

Spark’s execution profiler uses sampling. Short activities might be missed; higher percentages are not automatically proportional to user-visible latency. Read both parent and child call stacks.

Verify the result

  • Document the exact branch and share the viewer link with the responsible plugin author if needed.
  • Repeat the same workload and confirm the identified branch shrank without harming gameplay.
  • Use MSPT and TPS alongside the trace for end-user impact.

References