Diagnose Minecraft lag with TPS, MSPT and spark

Record what players experience before changing RAM or configuration. Low frame rate on one computer, delayed network traffic and a slow server tick need different investigations. A short report captured while the problem happens is more useful than a list of settings changed afterwards.

Identify the type of lag

Client frame rate: movement looks choppy on one player's screen, while other players and server timings remain normal. Test without shaders or a heavy client resource pack.
Network delay: chat, actions or movement arrive late for some players. Compare affected locations and connection times; record disconnect messages.
Server tick delay: several players see delayed mobs, block changes or commands at once. Check tick timings during that event.

A server targets 20 ticks per second (TPS), giving each tick a 50-millisecond budget. MSPT means milliseconds per tick. Sustained tick work above that budget lowers TPS. A healthy average can still hide short spikes, so record when the interruption occurs.

Capture a bounded spark profile

Paper bundles spark from Minecraft 1.21 onwards. For an older build or another loader, check the compatible spark installation instructions before adding it. Do not install a second copy without checking how that server loads the profiler.

Wait until the affected players and workload are present. Note the time, timezone, player count and activity.
In the game-panel Console, run this without a leading slash:

spark profiler start --timeout 60

Let the one-minute capture finish and save the report URL. Use a leading slash when entering commands in Minecraft chat, with the required permissions. For intermittent long ticks, a separate targeted capture can help:

spark profiler start --only-ticks-over 100 --timeout 60

This second example samples ticks over 100 milliseconds. It can miss shorter stalls, and an empty report does not prove that players had no network or client problem. Keep captures bounded rather than leaving diagnostics running without a plan.

Read the report in context

Check the capture period and tick timings before expanding the main server thread. Look for repeated expensive work associated with a plugin, entity processing, chunk generation or storage access. A large percentage identifies where sampled time went; it does not by itself prove a plugin defect.

Compare the same workload after one reversible change. Examples include reducing a specific plugin's scheduled work or testing a lower view distance during maintenance. Back up configuration first. Avoid deleting entities, removing world regions or disabling the watchdog as a generic fix. Those changes can destroy progress or hide a stalled process.

Send useful evidence

Include the report URL, affected time and timezone, software/build, player count and recent changes. Review report sharing settings and sensitive contents before posting publicly. Send CloudExa support private evidence if several services fail together or the panel also times out. Extra RAM may help ~~guide.~~a memory-bound workload, but it does not repair every slow tick.