Collect disk I/O evidence without running a write benchmark

Slow saves or database requests can come from storage waits, CPU contention, application locks or memory pressure. A write benchmark adds load and can make an incident worse. Collect a short observation window instead. These examples target Debian or Ubuntu guests. They read counters; they do not write a benchmark file or modify disks.

Prepare a useful time window

Record the start time and the user-visible symptom. Check whether a backup, import or package update was already running. Keep one affected request or operation available for comparison, but avoid deliberately flooding the application. Measurements taken during normal service are more useful than an unexplained peak from a synthetic workload.

date -Is
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
findmnt -T /srv/example
vmstat 1 10

Replace the path with the application's data directory. Device names in a VM may represent virtual disks rather than individual physical drives. A guest cannot establish the host's disk model or pool health from its own virtual device name.

Observe disk and process counters

If sysstat is already installed, run the following short samples. Do not install packages in the middle of an incident without considering repository availability and the extra work it creates.

iostat -xz -y 1 10
pidstat -d 1 10

The first command skips its initial since-boot report using -y. Check iostat --help if the local release differs. Keep the whole sample, including device names and timestamps. Process information may require sudo for complete visibility.

Look for changes in throughput, request latency and queue length during the symptom. A high utilisation value on a virtual or parallel device is not a universal proof of saturation. The meaning depends on how requests are queued and serviced. Read the installed manual for the columns your sysstat version prints rather than applying a single threshold copied from another machine.

Correlate instead of guessing

Compare the disk sample with vmstat: sustained swap activity may explain extra I/O, while a busy application can create work without the disk being the original bottleneck. Review recent application logs for lock waits or slow queries. If a process appears responsible, identify its job before stopping it. Interrupting a backup or database write can create a second incident.

Use df -h and df -i to check block and inode space. Latency diagnosis and capacity diagnosis are separate tasks. A filesystem that is full needs careful cleanup or expansion; no benchmark can fix it.

Package evidence for escalation

Send the affected service ID, UTC time range, symptom and short samples. Redact filenames and command arguments containing customer information. If guest counters show waits without an obvious guest process, ask hosting support to correlate the same interval with hypervisor and storage metrics. Do not conclude that a physical drive failed from one guest latency spike.

There is no configuration rollback for these read-only samples. Stop observation after enough evidence is collected; leaving verbose monitoring running indefinitely can create unnecessary logs and distract from the actual timeline.

Find disk-space use. Investigate systemd services.

Reference: Official documentation. Check the documentation installed on your own operating-system release when an option differs.