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. Increase autosave-interval (vanilla and some Paper-likes)

In server.properties:

autosave-interval=12000

This doubles the interval to 10 minutes. The freeze still happens, but half as often. Reasonable for a chill community server; bad for a death-streak survival server where losing 10 minutes of progress on a crash hurts.

Caveat: Many Forge and NeoForge modpacks override this setting through their own config (Sable, FerriteCore, or the modloader's world-save coordinator). If server.properties seems to be ignored, check the modpack's own config/ tree for a save-interval knob. Common locations:

• config/sable.toml (Sable mod)
• config/forge-server.toml (Forge server config)
• config/neoforge-server.toml (NeoForge equivalent)

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
autosave-interval=6000          # leave default; players notice 10-min loss more than 1-sec freeze

# 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 before bumping autosave-interval; players notice missing terrain less than a longer save window.

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 and surfaces save-tick duration in the panel? See plans. Every tier includes daily backups, one-click modpack installs, and the Doctor tab that flags save-tick anomalies before your players do.