VPS disk latency: how to find slow storage without guessing

Measure service time and queueing together

Use iostat or equivalent counters to inspect read/write latency, queue depth, throughput, and utilization during the slow period. A high throughput number can be healthy if requests complete quickly; a modest throughput number can be painful when every synchronous write waits a long time.

For databases, compare storage latency with query timing and checkpoint or flush behavior. For web workloads, compare it with request latency and PHP/application worker occupancy.

Identify the I/O producer

iotop, process accounting, database statistics, and application logs can reveal who is reading or writing. Common surprises include verbose logs, temporary files, backups, image processing, package updates, swap traffic, and a database doing maintenance after a change.

A full filesystem is a separate incident. Check free space and inodes first so a capacity failure is not misdiagnosed as a latency problem.

Distinguish sequential work from random synchronous work

Large sequential transfers can consume bandwidth while remaining efficient. Small random synchronous writes often expose latency more directly. The right mitigation depends on the access pattern, filesystem, database settings, and durability requirements.

Do not disable durable writes or fsync merely to make a benchmark graph look faster; that changes the failure semantics of the application.

Retest after moving noisy work

Schedule backups, imports, compression, or report jobs away from peak traffic when possible, and keep independent recovery copies off the live filesystem. If normal application I/O still exceeds the plan, resize or redesign based on the measured pattern.

• Capture latency during the actual incident.
• Find the process generating I/O.
• Check swap and filesystem capacity.
• Retest after separating background jobs.