RASP probe B - please ignore delete me

Probe.

at are non-zero, you're I/O-bound because you're memory-starved, not because the disk itself is slow. The fix here is more RAM or trimming what's running (drop unused PHP-FPM pool workers, lower MySQL's innodb_buffer_pool_size to something that actually fits), not disk tuning.

Step 3 - Find the specific process

If iotop is installed:

iotop -oPa

This shows only processes actively doing I/O, sorted by accumulated disk usage. No iotop? Use pidstat instead:

pidstat -d 2 5

Look at the kB_wr/s and kB_rd/s columns - whichever PID dominates is your target. Cross-reference the PID with ps -p <pid> -o user,cmd to see which cPanel account or service owns it.

Step 4 - Check per-device saturation

iostat -x 2 5

Column	What it tells you
%util	How saturated the device is; sustained 90-100% means the disk is the bottleneck
await	Average time (ms) a request waits - anything consistently above 10-20ms on SSD-backed storage is bad
r/s, w/s	Reads and writes per second - compare against what your plan's storage is actually rated for

Step 5 - Apply the fix that matches the cause

• Swap thrashing: upgrade RAM, or reduce MySQL/PHP-FPM memory footprint so the working set fits without swapping.
• Backup/scan overlap: reschedule to low-traffic hours and stagger so backup, malware scan, and cron jobs never run concurrently.
• MySQL flush pressure: if durability requirements allow it, set innodb_flush_log_at_trx_commit=2 and tune innodb_io_capacity to match your actual disk throughput rather than the conservative default.
• Noisy neighbor: if iostat shows high await with low local I/O demand from your own processes, that's a hosting environment problem - move to a plan with dedicated NVMe rather than shared storage.
• Failing disk: run dmesg -T and scan recent output for ATA or I/O errors, and if you have hardware-level access, smartctl -a /dev/sda. Sector errors mean it's time to migrate off that volume, not tune around it.
• Runaway logs/tables: truncate or rotate oversized logs, and add missing indexes on tables that show up in the MySQL slow query log doing full scans.

Prevention: Catch It Before the Site Feels It

• Add wa% and await to whatever monitoring you already run (even a simple cron job logging vmstat 1 1 every five minutes to a file is enough to spot patterns).
• Never schedule backups, malware scans, and log rotation in the same cron window - stagger them by at least 30 minutes.
• Set a swap alert, not just a disk-space alert - swap usage climbing steadily is an early warning that I/O wait is coming.
• If your database and web files share one volume, consider separating hot MySQL data onto its own disk once traffic grows - it isolates database write pressure from static file serving.
• Re-check iostat -x after any traffic spike or new plugin install; a new caching layer or logging plugin is a common silent cause of new I/O pressure.

If you're on a Getwebup VPS and consistently seeing %util pinned near 100% even after ruling out swap, backups, and MySQL flush settings, that's worth a support ticket - we can check the underlying storage tier and, if needed, move your account to a less contended volume.