Choose a main-thread or all-thread spark recording
Applies to: spark; match the linked maintainer documentation to your installed platform and release.
Documentation checked .
Minecraft tick performance and total process activity are related but different measurements. A main-thread profile can explain expensive tick work, while an all-thread capture can expose activity elsewhere. Selecting the wrong view can make a busy background worker look like the direct cause of low TPS.
Record the starting point
Record whether the symptom is slow ticks, high process CPU, delayed background work or a server that appears to wait. Keep the timestamp and a health snapshot. Use a bounded recording window so an exploratory profile does not run indefinitely.
Work through the change
- Start with the normal server-thread profiler for a tick-performance complaint. Repeat the relevant action and note the player count and workload during the capture.
- If background activity is the question, check command help and use the documented all-thread option, such as
/spark profiler start --timeout 120 --thread *. - In the viewer, inspect the selected thread and its call branches. Compare runnable work with waiting or sleeping states instead of counting every visible thread as active CPU consumption.
- Keep main-thread and all-thread reports labelled separately. Use the same workload for a follow-up capture after a candidate change.
Check the result
The selected report should answer the original question: what consumed tick time, or which background worker was active. Record the thread and time window alongside any screenshot. A high percentage within one selected thread does not automatically equal that percentage of total machine CPU.
If the result differs
If the server is waiting on storage or another service, a CPU-heavy branch may not explain the delay. Compare the observed symptom with spark's metrics and relevant logs. Avoid blaming whichever plugin name is easiest to recognise in a large thread list.
Stop or cancel a recording through spark's controls when enough evidence exists. Restore any trial configuration that does not improve the same workload. Keep performance investigation separate from data cleanup; profiling itself does not justify deleting plugin files.
No comments to display
No comments to display