Direct answer

Disk I/O lag occurs when storage reads or writes delay chunk loading, saving or database operations. Measure disk pressure during the spike before assuming the CPU or heap is the problem.

What it means

Backup compression, region saves, SQLite databases and hosting-neighbor activity can contend for storage bandwidth or latency. A large world file alone is not evidence of slow storage.

If you are a player

  • Note whether lag coincides with exploring new terrain, autosaves or scheduled backups.
  • Check whether block interactions lag while ping remains normal; this may indicate server-side waiting.

If you run the server

  1. Correlate logs and spark profiler samples with disk metrics; on Linux, iostat -xz 1 requires the optional sysstat package.
  2. Check whether scheduled backups, log rotation or database maintenance coincide with the stall.
  3. Inspect free space and filesystem errors before moving data.
  4. Compare the same workload after staggering backups or changing one storage bottleneck in staging, keeping the world identical.

Confirm the fix: A fix should reduce measured I/O wait and the matching chunk/save delays. Migrating to faster storage without profiling may not address a CPU-bound problem.

Important notes

  • More allocated RAM does not make a slow main-thread workload faster. Change heap size only when memory/GC evidence supports it.

References

Use the documentation for the exact software and release you run. These sources support the settings or diagnostic behavior used in this fix.

Was this article helpful?
Help us improve this article

Tell us what is missing, unclear, outdated, or incorrect. You can also suggest something we should add.

What could we improve?
Do not include passwords, server IPs, or other private information.0 / 1000