Check memory and garbage collection before adding more RAM.

Describe the memory-related symptom.

An out-of-memory crash, periodic garbage-collection pauses and sustained expensive ticks are different observations. Record the timestamp, the Java version, the configured heap limit and relevant messages. Keep a short log excerpt rather than assuming any high memory graph means a leak.

Java uses heap memory as part of normal operation. A busy process or high used-memory percentage alone does not show that garbage collection caused the player-visible stall. Correlate the symptom with actual collection or failure evidence.

Capture the same window from more than one angle.

Keep a server profile during the complaint and the relevant JVM or Spark memory observations. Spark provides commands for GC history and monitoring; use its current documentation for the version you run. Host metrics can add context about the process, available system memory and other workloads.

TickVisor analyzes supported uploaded diagnostics. It does not replace a dedicated heap investigation or claim to ingest .hprof heap dumps. Retain the original evidence and use the appropriate tooling when the question is which objects remain live in memory.

Look for the activity that changes allocation or retention.

Record whether the problem follows exploration, a pack update, a growing automation network or long uptime. Those observations suggest a test; they do not establish a cause. A mod or library appearing in a profile may need deeper review before a leak or defect can be attributed.

Try to reproduce the issue on a staging copy with one controlled change. Keep the same Java and pack versions unless a version change is the specific test. Changing runtime, heap size and mods at once makes an improvement difficult to interpret.

Avoid universal heap sizes and copied flag bundles.

Heap sizing depends on the pack, world, player activity and available system resources. More heap is not a universal cure for slow ticks, and assigning memory without leaving room for the rest of the system can create other problems. Consult the pack and platform guidance for your versions.

Do not copy a long Java-argument list from an unrelated server and assume it is an optimization. Explain the reason for each runtime change, preserve the original configuration and measure its effect. For a hosted server, include the provider when the plan or process limits are part of the question.

• Preserve the original runtime configuration.
• Record collection timing alongside the lag window.
• Separate a crash diagnosis from an ordinary usage graph.
• Test one runtime or workload change at a time.

Validate the improvement over a useful time window.

A short smooth period after a restart may only postpone the condition that triggers the issue. If it normally appears after hours of play, include that time scale in the follow-up. Record whether the same players, dimensions and automation were active.

Compare supported before-and-after reports and the accompanying memory evidence. State what was measured, what changed and what remains uncertain. When escalating, remove secrets and unrelated personal data; do not upload a broad backup or heap dump to a tool that does not support it.