Direct answer

Once the server has sufficient heap for its live working set, extra heap may have diminishing returns. It does not fix an overloaded tick thread, slow plugin or host CPU quota.

How to check it

  1. Record -Xmx, JVM version, player load, GC behavior, system available RAM and any container OOM events.
  2. Use spark/GC logs to see whether pauses or allocation pressure really coincide with lag.
  3. Compare used heap after normal GC with host memory headroom; avoid conclusions based only on the panel memory graph.

What to change

java -Xms4G -Xmx4G -jar paper.jar --nogui
# Illustration; size based on measured workload and host limit.
  1. If the heap is oversized for the physical/container limit, reduce it in a controlled test while keeping enough working-set space.
  2. Prioritize profiling entities, chunks and plugins when MSPT stays high but GC is healthy.
  3. If the application truly runs out of heap, investigate plugin/mod retention and workload before blindly raising Xmx.

Software and version notes

Compatibility and safety

PaperMC notes that a very large heap can waste RAM and recommends leaving memory beyond Xmx for operating-system and native overhead. Actual values depend on workload and plugins/mods.

Verify the result

Retest startup, peak TPS/MSPT, GC log pauses and cgroup/system OOM events after changing only the heap allocation.

References