How to Fix High iowait on Linux

What Is iowait?

The iowait metric represents the percentage of time CPUs spend idle while waiting for disk I/O operations to complete. High iowait (consistently above 10-20%) indicates your Breeze is disk-bottlenecked, causing sluggish performance across all applications.

Step 1: Confirm the Problem

# Real-time CPU stats including iowait (wa column)
vmstat 1 10

# Per-CPU breakdown
mpstat -P ALL 1 5

# Quick snapshot
top -bn1 | head -5

Step 2: Identify the Disk Bottleneck

# I/O stats per device
iostat -xz 1 5

# Key columns to watch:
# %util - percentage of time device is busy (>80% = saturated)
# await - average wait time in ms (>10ms for SSD = issue)
# r/s, w/s - reads and writes per second

Step 3: Find the Culprit Process

# Show processes with highest I/O
iotop -oP

# If iotop is not installed
sudo apt install iotop -y

# Alternative: check /proc for I/O stats
pidstat -d 1 5

Common Causes and Fixes

Excessive Swapping

# Check swap activity
vmstat 1 5  # Look at si/so columns

# Reduce swappiness
sudo sysctl vm.swappiness=10
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

MySQL Without Proper Tuning

# In /etc/mysql/mysql.conf.d/mysqld.cnf
innodb_buffer_pool_size = 1G      # 50-70% of available RAM
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2  # Slight durability trade-off for performance
innodb_io_capacity = 2000           # Increase for SSD

Aggressive Logging

# Find large log files being written to
lsof +D /var/log 2>/dev/null | head -20

# Rotate logs
sudo logrotate -f /etc/logrotate.conf

Long-Term Solutions

• Upgrade to an SSD-backed Breeze plan if using spinning disks
• Add RAM to reduce swap usage and increase filesystem cache
• Implement application-level caching (Redis, Memcached) to reduce database I/O
• Move temporary files and logs to a separate disk