Capture a useful Spark profile from a modded Minecraft server.
The best profile records the problem you need to explain. Prepare the capture so you can reproduce its workload and understand what changed afterward.
Check the platform and Spark version.
Use a Spark build that matches your Minecraft version and server loader. Current Paper releases include Spark; modded platforms need a compatible mod build. Do not copy a plugin JAR into a mod loader or assume one download supports every historical pack.
Confirm that you have profiling permission. Use a server capture for server-tick questions; a client profile records a different workload. Check the installed version’s command help if an argument differs. Official Spark and platform documentation is the reference for installation details.
Record the conditions before starting.
Write down the pack and loader versions, Java version, relevant settings, online players and the symptom’s timestamp. Note whether players are exploring, moving between dimensions or visiting an automation-heavy base. Identify whether the issue happens in one place or everywhere.
A freshly restarted empty server may not reproduce a problem from a busy evening. If the symptom appears only after the world has been running for some time, record that condition as part of the test.
- Describe the action that causes the symptom.
- Record active dimensions and loaded bases.
- Note recent settings or mod changes.
- Keep the original profile for later review.
Capture the problem, then save the file.
Start a time-bounded server profile during the issue. The example below records ten minutes; choose a window appropriate to the problem and your operational procedures. A longer idle capture does not compensate for missing the expensive workload.
Spark can save a stopped profile to a local file instead of uploading it to the viewer. Retrieve the resulting .sparkprofile from the location reported by your version. TickVisor expects the diagnostic file; a browser link to a viewer is not a file upload.
/spark profiler start --timeout 600A time-bounded capture example documented by PaperMC.
/spark profiler stop --save-to-fileSpark’s local-file export option. Check the reported save location.
Keep spike-focused captures separate.
For rare stalls, identify the timing and trigger before filtering. Spark’s tick monitor and slow-tick filtering can help isolate the work recorded during slow ticks. Keep the mode and threshold in the capture notes.
A targeted profile does not represent the entire normal session. Retain an unfiltered representative capture as well when practical, and compare like with like. Avoid interpreting a filtered percentage as an all-session cost.
Share only what the investigation needs.
Review logs and bundles for tokens, credentials and unrelated player information before sharing them. Do not upload heap dumps or broad server backups simply because they exist. Follow TickVisor’s supported file list and keep the diagnostic scope focused.
Upload the profile, read the summary and timing confidence, then retain the original file. Relevant logs can explain failures alongside a profile; they cannot recover the tick workload from a different moment.
Create a fair second capture.
Apply one reversible change and capture comparable activity again. Keep versions, profiling mode and player workload as similar as practical. Note unavoidable differences instead of hiding them behind one grade.
Compare tick pressure and grouped systems in the second report. If there are fewer loaded bases or players, treat an improvement as a lead to test again. A repeatable workload gives a support team stronger evidence than a smooth minute after a restart.
References and further reading
Commands and platform behavior can change. Check the official documentation for your installed versions.
Turn your next capture into a clearer decision.
TickVisor analyzes uploaded files. You choose the fix and validate it with another capture.