Lag when players fly toward new biomes does not prove that the server cannot generate chunks fast enough. Existing chunks may be slow to read or send, while the client may struggle to render them. First match the gameplay symptom to server ticks, then choose a fix.
This guide uses Paper 1.21 and newer as its concrete baseline because those versions bundle Spark. On Fabric, NeoForge, Forge, Velocity, or an older build, first check that the Spark plugin or mod you plan to install supports your loader and version. Do not drop an arbitrary JAR into plugins or mods.
Record what is actually happening#
Before profiling, note the server build, Minecraft and Java versions, player count, approximate location, and when the issue starts. Check whether players are crossing new or previously explored terrain, whether the delay repeats after they stop, and which players see it. Do not run this diagnosis during large-scale world pregeneration.
Separate three observations:
- High MSPT or falling TPS during the stutter: the server is taking longer to process game ticks. Generation is one possible cause; also inspect entities, mods, and plugins.
- Normal ticks, but new chunks arrive late: gather separate evidence about disk reads, queues/asynchronous loading, the network path, and chunk delivery. A CPU profile alone cannot measure all of those layers.
- Server metrics look normal while one player sees stuttering: check client FPS and rendering settings. The problem may not be on the server.
Admincraft discussions show why these cases should not be collapsed into one diagnosis: slow loading while flying across already generated terrain, a profile with normal TPS but slow chunk delivery, and lag that remained after pregeneration describe different symptoms and do not establish one universal cause.
Capture a profile while reproducing the issue#
Spark is already included in Paper 1.21 and newer. The command requires operator status or a configured Spark permission. Start a time-limited profile before reproducing the problem:
spark profiler start --timeout 300
For up to five minutes, repeat the usual route or wait for a typical stutter; do not deliberately create an extreme load on a live world. The profile stops when the timer expires. To stop it earlier, run:
spark profiler stop --save-to-file
Inspect the result and find the Server thread: Spark describes it as the main thread responsible for running the game. Expand the profile-tree nodes with the largest shares instead of drawing a conclusion from one method name. A large share of world-generation work during the same period as the stutter is a reason to investigate that path further, not proof that a particular disk or CPU is at fault.
An average profile can hide a rare long tick. For short, recurring freezes, you can enable the tick monitor:
spark tickmonitor
Once you correlate a long-tick report with an in-game action, capture a profile only for ticks above a chosen threshold, for example:
spark profiler start --only-ticks-over 100 --timeout 300
The example threshold is a starting point for observation, not a performance standard. Compare it with the stutters you actually observe. Toggle the monitor off by running spark tickmonitor again. Finish the profile locally with spark profiler stop --save-to-file; the server saves a file without uploading it to the online viewer. If a web report would help, get the world owner's consent, inspect its contents, then choose to upload it deliberately. Profiles can expose player names and configuration details.
Compare new terrain with already generated terrain#
Repeat the same short route through new terrain and then through a known explored area with a similar player count and load. Do not change the server build, plugins, world settings, and Java arguments at the same time; otherwise the comparison cannot tell you what mattered. Back up the world before making changes.
If long ticks coincide with new terrain generation, inspect the world-generation and mod/plugin branches in the profile. Check whether the issue began after adding a generator, updating the server, or changing its settings. You can separately evaluate pregeneration in a bounded test area with a compatible tool, but players may feel extra load during the process and the world will need additional disk space. Do not start a large radius without calculating its impact, and do not delete region files as a test.
If MSPT stays healthy while chunks arrive late, collect separate data on disk latency, available bandwidth, packet loss, and chunk-sending settings. A server implementation may load some chunks asynchronously, so a profile of the main thread may not reveal a wait. Compare symptoms across players and, if possible, on one client; local rendering and the path to the server are different checks. For a server you manage, for example through Nexardo, take the Spark profile when the symptom occurs: a control panel does not replace measuring game ticks.
Fix only the bottleneck the evidence points to#
- If the profile points to world generation or a specific mod/plugin, check its compatibility, settings, and reproducibility after making a backup. Change one factor at a time.
- If the profile shows prolonged entity work or plugin tasks, investigate that load instead of blindly replacing the CPU.
- If server ticks look healthy but the delay remains, investigate disk, network, chunk-sending distance, and client performance separately. Spark is not a network test or an FPS meter.
- Do not copy universal JVM flags or increase memory without evidence. Java configuration depends on the server build, runtime, and machine limits; flags do not fix every kind of delay.
For a useful report, keep the server version, loader, Java version, profile time, exact route, TPS/MSPT before and during the issue, recent changes, and the client-side symptom. Admincraft questions about whether CPU, RAM, or an HDD affects generation speed show why a reproducible profile is more useful than guessing an upgrade from the word “lag.”
