Modded Minecraft Save Tick Lag - Multi-Dimension Packs

Why a heavily modded Minecraft server freezes every five minutes

You are running a modpack with planetary or otherworld dimension mods - NorthStar, CreatingSpace, Wyvern Lair, Beyond Earth, or any of the larger overhaul packs that ship a dozen dimensions out of the box. Every five minutes, the world freezes for a second or two. TPS drops, players see rubberbanding, and your CPU graph shows a regular saw-tooth. This page explains exactly what is happening and what you can do about it.

What the freeze is

Minecraft Java auto-saves every 6000 ticks by default - that is exactly 5 minutes at 20 ticks per second. During an auto-save, the server walks every loaded chunk in every loaded dimension, writes any dirty chunks to disk, and then resumes the tick loop. On vanilla with one or two dimensions and a handful of loaded chunks per player, this is fast enough to be invisible.

On a modpack that adds planetary travel, void dimensions, dream realms, or otherworld layers, the same auto-save now walks ten, fifteen, twenty dimensions. Even if most of those dimensions have only one or two players' chunks loaded, the per-dimension iteration overhead piles up, and the save tick lengthens from a few hundred milliseconds into the multi-second range.

From the log, the signature is unmistakable:

[Server thread/INFO] [<modloader>/]: Saving sub-levels for level 'ServerLevel[world]'/{
  minecraft:overworld,
  minecraft:the_nether,
  minecraft:the_end,
  creatingspace:the_moon,
  creatingspace:mars,
  northstar:moon,
  northstar:mars,
  northstar:venus,
  wyvernlair:wyvern_realm,
  ...
}

Every dimension listed in that block gets iterated. If you see the line in latest.log on every 5-minute interval and your dimension count is in the double digits, you have found your stutter.

Mitigations, ordered cheapest first

1. Do not look for an auto-save interval in server.properties

There is no such key. Minecraft Java schedules the auto-save in its own code: one save every 300 seconds, which is 6000 ticks at 20 ticks per second, and the server recomputes it if you change the tick rate with /tick rate. No Java version from 1.20 to 26.3 reads an auto-save setting from server.properties, so an autosave-interval line copied from a guide is silently ignored. NeoForge, Forge and Fabric run the same server loop, so the interval stays at 5 minutes on a modpack too unless one of its mods changes it. The levers that do work are the ones below: fewer chunks and fewer dimensions to save, and faster hardware to save them on.

2. Reduce view-distance

In server.properties:

view-distance=8
simulation-distance=6

Each chunk further out is a chunk that has to be checked during save. Dropping from 12 to 8 cuts the per-dimension chunk count by about 55%. Players see slightly less terrain pop-in but rarely complain - they get smoother gameplay in return.

3. Drop unused dimensions from the modpack

This is the largest single win. If your community plays mostly in the overworld and rarely uses three of the planet mods, removing those mods from the pack cuts the dimension count and the save-tick cost in one move.

Identify candidates by reading latest.log for the auto-save line and noting which dimensions are listed. Any dimension that shows up in the save list but never gets a "Player entered dimension X" log line over a play session is a candidate for removal.

4. Move to a plan with more RAM headroom and faster disk

The save iteration is bound by:

• CPU - for the chunk traversal
• RAM - for holding the dirty chunks before flush
• Disk I/O - for the actual write

If your CPU is fine but the save stutter persists, the bottleneck is usually disk. NVMe-backed nodes complete the same save in under a second where SATA SSD nodes take three to five. RAM matters because a memory-pinched server starts paging during the save, multiplying the freeze duration.

5. Switch to a non-Forge modloader where viable

For packs that have a Fabric or Quilt equivalent, the Fabric world-save path is often faster than the Forge equivalent because of looser global locking. This is not always an option - many heavy packs are Forge-only - but if you have the choice, the same content on Fabric is typically 10-25% cheaper at save time.

What does not help

• Disabling auto-save entirely. Inevitable crash; lose hours of progress. Do not do this.
• Adding more cores. The save iteration is on the main server thread; extra cores sit idle.
• Reducing player count. Players' loaded chunks contribute some cost, but the dimension count contributes more on these packs.
• Restarting more often. Restarts do not change the per-save cost.

How to confirm save is the cause

Two checks confirm it before you start optimising:

1. Time the stutter. Have a player chat or move during the freeze. Note the wall-clock time. Repeat. Are the stutters spaced 5 minutes apart, almost exactly? If yes, save is the cause.
2. Match log lines. In latest.log, search for Saving sub-levels. Note the timestamp. Compare against your player's wall-clock reports. If they match within a few seconds, save is the cause.

If the stutters are at irregular intervals, the cause is something else - probably garbage collection, a specific mod's periodic tick, or a runaway entity. Different debugging path.

Diagnostic: which dimension is the slowest?

The Sable / Forge-server log writes a Saving sub-levels line per save. Some modloaders extend this to log per-dimension duration. Read your latest.log for any line shaped like:

[Server thread/DEBUG] [worldsave/]: Saved dimension 'creatingspace:mars' in 184ms

If your loader logs durations, the dimension with the largest single timing is the one driving your stutter. Removing or disabling that dimension is the highest-leverage win.

A sane starting config for a heavy modpack

For a Cobbleverse-style or NorthStar-style pack on a 32 GB RAM plan with NVMe:

# server.properties
view-distance=10
simulation-distance=8

# JVM heap (separate config)
-Xms24G -Xmx24G -XX:+UseG1GC -XX:+ParallelRefProcEnabled
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions

If players keep complaining about the every-5-minute freeze even at this config, drop view-distance to 8 and look at the dimension list next; the interval itself is not a setting you can raise.

Related guides

• Minecraft modpack server hardware sizing
• Aikar's JVM flags reference
• Fixing Minecraft server lag (general)
• Spark profiler usage
• Cross-game: what CPU 200%+ actually means

Want a Minecraft modded host that ships on NVMe by default? See plans. Every plan has automatic backups, and Plans M and L run Forge, NeoForge and Fabric and install Modrinth modpacks from a link.