Direct answer

World-save lag is a timing diagnosis, not a reason to disable saving. Match the spike to a save operation, then test whether serialization, plugin hooks or disk write latency is dominant.

How to check it

  1. Save a valid backup before changing any storage or world setting. Record the world names, server type and relevant save/backup schedules.
  2. Collect server logs during a suspected save stall. In a controlled environment, run /save-all and record if it causes repeatable tick delays.
  3. Start /spark profiler start --timeout 180 before the event and inspect server-world save/chunk I/O branches and plugin callbacks.
  4. Check host disk capacity, storage health and competing backup processes; on Linux monitor disk latency if tools are available.
  5. Repeat the test with an equivalent world/player load, comparing the event timing and profiler branches.

What to change

  • Avoid overlapping large backup/compression jobs with busy-world saves; use host-native snapshots only when consistent with the application state.
  • Investigate any plugin that serializes large structures or hooks into save operations before raising save intervals.
  • If disks are saturated, verify free space, filesystem errors and storage capacity; do not move live world folders while the server is writing.

Software and version notes

Changing auto-save schedules or disabling world saving can risk data loss. Commands and save pipeline internals differ by server software; read your software’s exact documentation.

Verify the result

  • Confirm world files still save and load after a normal restart.
  • Repeat the same save scenario and compare stall durations and spark samples.
  • Keep a recoverable backup and record any data consistency anomalies immediately.

References