Diagnose lag in heavy Minecraft modpacks.

The workload matters more than the mod count.

A long mod list is not a diagnosis. A small set of active machines can consume more tick time than many installed mods that are idle. Players exploring new terrain, multiple loaded bases, automation networks and entity AI all change the work your server must do.

Large kitchen-sink packs and automation-heavy worlds need profiling under their actual workload. Record the pack version, loader, Java version, player count and what was happening when the capture was taken. A quiet test immediately after a restart can hide the issue that appears during normal play.

Separate the symptoms before choosing a fix.

Start with server tick time. Low client FPS, high network latency and slow server ticks can feel similar to a player, but they call for different investigations. A server-side Spark profile is useful when the server is taking too long to process its ticks.

If TPS is healthy during the complaint, do not immediately remove server mods. Check whether the affected player has rendering trouble or a network issue. If tick time rises while players visit a specific base, reproduce that activity and capture it.

• Sustained high MSPT: inspect the work that remains expensive throughout a normal session.
• Short spikes: capture the action that triggers them, rather than relying only on an average.
• Crashes or repeated errors: add a relevant log or crash report to the investigation.

Turn the capture into a practical priority.

Upload a .sparkprofile file to TickVisor. The report groups profiler detail into systems such as entity ticking, block entities and chunk work, with attribution signals and likely causes to help you decide where to investigate first.

Attribution is a lead, not proof that the named mod is defective. A common library or event bridge can appear prominently because it dispatches work for something else. Keep the original Spark capture available and review the context behind the grouped result.

Change one thing and capture again.

Back up the server before changing world data, removing mods or testing a pack update. Prefer a staging copy for changes that can affect saves. Begin with a reversible change tied to the observed hotspot: pause one automation network, inspect a loaded area or test a specific configuration option.

Take a second capture with comparable player activity and settings. Use report comparison to check whether tick cost improved and whether the expensive work moved elsewhere. A lower percentage alone does not prove an improvement if the total workload also changed.

1. Capture the issue during representative load.
2. Review tick pressure, top systems and attribution context.
3. Choose one reversible change and note it.
4. Capture comparable load again and compare the reports.

Know what the tool does.

TickVisor analyzes uploaded files. It does not install an optimization mod, automatically edit your server, guarantee a lag-free pack or provide continuous node monitoring. Logs and diagnostic bundles can add context; they do not turn an idle capture into evidence of a problem that happened later.

Start with two uploads after email verification. Pro and Network add monthly report capacity, and AI analysis uses separate optional credits. Check the current plans against the number of before-and-after captures you expect to review.

Common questions