Direct answer

Look for storage latency at the same time as world loading or saving delays. High disk space used is not the same as slow I/O; a profile alone cannot measure every filesystem bottleneck.

How to check it

  1. Record when the freeze happens: chunk loading, backups, world saves, player joins or region-file writes. Check server logs for I/O errors.
  2. On Linux, run df -h for space and df -i for inode exhaustion. Check your hosting panel for disk throttling or quota limits.
  3. Where available, run iostat -xz 1 (from the sysstat package) during the issue and observe device utilization and await/latency rather than just throughput.
  4. Take a spark profile during the event with /spark profiler start --timeout 180; inspect file I/O or chunk serialization branches, recognizing that wait time is not always captured as CPU.
  5. Compare with a quiet period and check whether another job, backup, antivirus or shared-host workload is running concurrently.

What to change

  • Move heavy backups or compression away from peak play periods where possible.
  • Ensure world data is on healthy, appropriately provisioned storage, and reduce avoidable chunk generation or save bursts.
  • If on shared hosting, provide timestamped latency and disk metrics to the provider rather than assuming a plugin issue.

Software and version notes

The Linux commands shown require system access and optional utilities; managed hosting panels may not expose them. Do not run uncontrolled disk stress tests on live world files.

Verify the result

  • Compare tick stalls, host disk latency and time to complete the same save/load scenario.
  • Check for disk errors and data integrity; restore from tested backups if corruption is suspected.

References