Original PortalMine editorial illustration. This page is maintained as practical server-owner documentation.
Quick answer: Garbage collection is normal. Investigate when pauses or allocation failures affect ticks, then confirm heap pressure, runtime compatibility, and workload before changing flags or adding memory.
Understand the heap cycle
A Java server allocates objects as chunks load, packets are processed, plugins run, and game state changes. The garbage collector reclaims objects that are no longer reachable. Memory usage rising and then falling is expected behavior, not proof of a leak.
The operational concern is pause time, frequency, and whether the application can reclaim enough space. A healthy server may use most of its configured heap during activity and recover after collection without visible player impact.
Distinguish collection pauses from general lag
Low TPS can occur with no significant garbage-collection problem. Use GC logs, runtime metrics, and tick timing to correlate pauses with player symptoms. If MSPT remains high between collections, the main bottleneck may be entities, chunks, plugins, or CPU performance.
Conversely, repeated long pauses followed by brief recovery can indicate memory pressure, an oversized live data set, or a runtime configuration issue. Diagnosis requires timestamps that can be compared across console, GC, and monitoring data.
Set heap below the container limit
The Java heap is not the process’s entire memory use. Native libraries, thread stacks, direct buffers, code cache, and the runtime itself also consume memory. Setting the maximum heap equal to the container limit can cause the host or panel to terminate the process even when the heap has not reached its own limit.
Leave explicit operating headroom and observe real resident memory. The correct gap depends on runtime, extensions, and workload, so measure on the actual server rather than copying a universal percentage.
Avoid treating more memory as a universal fix
Additional heap can reduce allocation pressure when the server genuinely lacks space, but it cannot make slow tick tasks faster. Very large heaps may also extend some collection work and make recovery from a memory leak take longer to become visible.
Increase memory only when logs and metrics show sustained pressure and the live workload justifies it. If a plugin retains data indefinitely, adding heap postpones the crash without removing the cause.
Use a supported Java runtime and conservative flags
Match the Java version required by the Minecraft and server software release. Unsupported runtimes or obsolete tuning guides can introduce startup failures and unpredictable behavior. Begin with the software project’s current recommendations and default collector behavior.
Change one group of flags at a time. Record the old command, runtime version, heap size, workload, and measurable result. A long list of unexplained flags copied from another host makes troubleshooting harder and may override modern runtime defaults.
Capture useful garbage-collection evidence
Enable GC logging in a format supported by the runtime and retain logs across restarts. Useful fields include collection type, pause duration, heap before and after, allocation failures, and total process uptime. Protect logs from unbounded growth with rotation.
Analyze patterns over a representative session: startup, exploration, peak players, backups, and shutdown. One isolated pause during startup is less important than repeated pauses during normal play.
Investigate leaks and retained data systematically
If the post-collection baseline rises continuously, compare behavior with optional plugins or mods disabled on a copy. Review known issues for the exact extension versions and inspect caches, maps, scoreboards, database queues, or generated objects that grow with player activity.
Do not collect or publish player data unnecessarily during diagnosis. Heap dumps can contain sensitive server and plugin information, so restrict access, store them securely, and remove them after analysis.
Validate changes with repeatable load
After changing heap or runtime settings, reproduce the same workload and compare pause percentiles, MSPT, process memory, and stability. A change is successful only if player-impacting pauses improve without new crashes or excessive host memory use.
Keep the final startup command simple and documented. Garbage-collection tuning should be the result of evidence, not a permanent collection of internet folklore.
Editorial review notes
This guide is written for small Minecraft communities and self-service hosting users. Exact commands, configuration names, compatibility, and limits can vary by edition, server software, runtime, host, and installed extensions. Test changes on a copy, keep verified backups, and consult the current documentation for version-specific requirements.