A practical checklist for heavy modpack server lag.
Use this sequence when a large pack slows down as a world matures. Build a repeatable diagnosis before changing settings or removing mods.
1. Define the symptom.
Ask whether simulation is slowing for everyone, one player is disconnecting, or a client struggles to render a base. Record the timestamp and duration. Name an observable behavior: delayed block updates, slow machines, stalls during exploration or low FPS near a build.
Check tick pressure during the same window. If the server stays healthy while one client struggles, begin with that client or connection. If ticks are slow for everyone, investigate server workload before recommending more memory or a hosting upgrade.
2. Preserve a baseline.
Record the pack, Minecraft, loader and Java versions, online players, dimensions and recent changes. Capture a Spark profile while the issue happens. Keep the original file and a relevant log excerpt, removing sensitive data before sharing.
A restart changes loaded chunks and active systems, so it is not a neutral optimization test. If it temporarily changes the symptom, record how long the problem takes to return and what players do in the meantime.
3. Follow the expensive system.
Use the capture to select an investigation. Entity work points toward active mobs, AI and loaded populations. Automation or block-entity work calls for inspecting machines, inventories and networks that are ticking. Chunk work needs separation into generation, loading and storage behavior.
A package name is not a verdict. Shared libraries, event dispatchers and runtime methods can appear prominently because they coordinate other work. Read the surrounding methods and gameplay activity before recommending a removal.
| Pattern | Useful next test |
|---|---|
| Stalls while exploring | Repeat in generated terrain and inspect generation work. |
| Slow ticks near a factory | Isolate that area’s activity on a protected staging copy. |
| Periodic world-wide pauses | Correlate spikes with GC, saves and scheduled tasks. |
| Healthy ticks, one player affected | Check the client, connection and route. |
4. Make one reversible change.
Back up the world and use staging for changes affecting compatibility or saved blocks. Tie the test to the evidence. Pausing one suspected network is easier to interpret than changing distances, Java flags and ten mods together.
Large packs do not all need identical entity limits or distances. Those settings also change gameplay. Explain the trade-off and verify that the option belongs to the actual platform and version you run.
5. Compare under similar activity.
Use similar players, loaded bases, dimensions and profiling settings for the next capture. Compare total tick pressure as well as system shares. Check whether the change simply moved work or removed the activity the owner wanted to support.
Document what changed, which signal improved and what remains uncertain. TickVisor provides history and comparison for uploaded reports; it does not continuously monitor the server between captures.
6. Escalate with a focused support bundle.
Provide the before-and-after files, exact versions, reproduction steps and a small relevant error excerpt. For a hosting concern, include the incident time so the provider can check node, storage and network telemetry.
Keep credentials, payment details and unrelated personal data out of the bundle. Treat likely causes as investigation priorities rather than a guarantee that one setting will solve the problem.
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.