Written by Thomas C. | 20+ years of enterprise Linux engineering
When a Linux server freezes while CPU use looks low, storage latency or memory pressure may be involved. A high io wait linux fix starts by separating those causes from a slow application, remote filesystem, or cloud limit. High I/O wait is a clue to investigate; it does not identify the failing device by itself.
Linux load average can rise when tasks are runnable or waiting in uninterruptible sleep. That can happen during storage waits, but load average alone does not prove that a disk is saturated. Compare repeated samples from the operating system with application logs and storage-provider metrics before changing production settings.
Is production affected now? OS Assistance can review Linux, database, web-server, and storage incidents. Request emergency Linux support. The $199 emergency plan includes a 1-hour response SLA; restoration time depends on incident scope and external dependencies.
High IO Wait Linux Fix: Start with vmstat and iostat
Take several samples while the slowdown is happening. If the tools are missing, install the distribution packages that provide procps and sysstat, following your change process.
uptime
vmstat 1 5
iostat -xz 1 5In vmstat, inspect the runnable and blocked task counts, swap activity, and CPU wait column. The first report can summarize activity since boot; use the following interval reports to see what is happening now. In particular:
ris the number of runnable processes;bis the number blocked waiting for I/O to complete.wais CPU time spent idle while I/O is outstanding. It is not a direct measure of disk utilization and does not identify which device is slow.siandsoshow swap-in and swap-out activity. Sustained movement during the incident is more useful than the amount of swap currently occupied.
In iostat, compare device latency (await), average queue size (aqu-sz), read and write rates, and %util. Do not treat a single value such as %util = 100 or an arbitrary millisecond threshold as proof of saturation. Interpret the metrics together, compare them with the server’s healthy baseline, and account for the storage type. Devices that handle concurrent I/O can make %util harder to interpret on its own. This gives a high io wait linux fix a consistent baseline for later comparison.
If you need a high io wait linux fix, this first comparison helps decide whether to look at a local block device, swap, a network filesystem, or a service waiting on another dependency. Repeat the samples during both normal and degraded periods when possible.
Find the process and device behind the I/O
After confirming that I/O latency rises with the slowdown, identify which workload is generating reads and writes. The sysstat tool pidstat can show per-process I/O activity:
pidstat -d 1 5Look for database queries or maintenance, backup and compression jobs, log bursts, search-index merges, package updates, and application tasks creating temporary files. A large writer is not automatically the root cause: it may be expected work competing for a volume with limited capacity.
List processes in uninterruptible sleep and inspect their wait channels:
ps -eo state,pid,ppid,comm,wchan:32 | awk '$1 ~ /^D/'
# Replace PID with a process ID from the output; root access may be required.
cat /proc/PID/wchanA process in D state cannot finish handling a signal until the kernel wait ends. Repeatedly sending kill signals or restarting services may not clear the underlying storage wait. The process list and device statistics together make a high io wait linux fix actionable: connect a waiting application to the device or remote dependency it is using. A useful fix should address that measured relationship instead of raising a generic threshold.
Check active swap and memory pressure
A high amount of used swap does not by itself mean the server is currently swap-thrashing. Check whether pages are moving in and out during the incident and whether memory pressure is affecting key services.
free -h
vmstat 1 10
ps -eo pid,comm,rss,%mem --sort=-rss | head -n 15If si or so stays active across several samples while application latency rises, inspect the largest processes, database memory settings, container limits, and recent workload changes. Check kernel and service logs for out-of-memory kills or repeated restarts:
journalctl -k --since "30 minutes ago" --no-pager
journalctl --since "30 minutes ago" -p warning --no-pagerDo not lower vm.swappiness or disable swap as a first response. Swappiness is a workload and kernel tuning control; the right value depends on memory pressure and the relative performance of RAM, swap, and storage. Test a proposed change under representative load and keep a rollback plan. A high io wait linux fix should address the memory shortage or workload that is driving page movement, not just hide one symptom.
Review writeback and kernel settings before tuning
Linux buffers writes in memory and writes dirty pages to storage in the background. The vm.dirty_background_ratio and vm.dirty_ratio settings influence when background writeback starts and when a process that is generating writes may itself begin writeback. Their byte-based counterparts are alternatives; the kernel uses either a ratio or a byte limit for each pair.
Inspect the current settings before proposing changes:
sysctl vm.dirty_background_ratio vm.dirty_ratio
sysctl vm.dirty_background_bytes vm.dirty_bytes
sysctl vm.dirty_expire_centisecs vm.dirty_writeback_centisecsDo not paste generic dirty-page values into a production server as a universal fix. A setting that helps one write-heavy workload can increase write throttling or reduce throughput for another. First check storage latency, write rates, filesystem messages, application behavior, and whether a known job coincides with the event. Change one setting at a time, document its previous value, and measure the result.
Review recent kernel messages for device resets, I/O errors, filesystem warnings, or out-of-memory events. On systemd systems, journalctl -k is a useful starting point. A full filesystem or exhausted inodes can also affect services; use df -hT and df -ih to check capacity. See our Linux disk-space recovery guide if storage capacity is part of the incident.
Check cloud volume and instance limits
Cloud storage has limits at both the volume and virtual-machine level. Compare the configured IOPS and throughput with the actual workload, then check provider metrics for throttling or exceeded limits. A larger volume or a new volume type can help only when the measurements point to a capacity limit; the instance may also cap total storage bandwidth.
For AWS EBS, BurstBalance applies to gp2, st1, and sc1 volumes. It is not the metric to use for gp3. For gp3, review the provisioned volume performance and CloudWatch indicators for IOPS or throughput limits, along with the EC2 instance’s EBS bandwidth. AWS currently documents a gp3 baseline of 3,000 IOPS and 125 MiB/s, but the effective performance still depends on the volume configuration and attached instance.
For other providers, check their current volume and instance performance dashboards and limits. If you are considering a volume modification, filesystem expansion, or migration, confirm the backup, snapshot, application, and rollback plan first. A provider-side change can affect cost and may not remove a bottleneck elsewhere in the stack. For a cloud host, a high io wait linux fix should match the metrics and limits of its actual volume and instance type.
Stabilize service, then verify the result
- Record the time of the slowdown and capture vmstat, iostat, process, application, and kernel-log evidence.
- Identify the workload or limit that matches the latency spike. If an approved backup, report, or batch job is causing contention, coordinate a pause or schedule change with its owner.
- Make one targeted change: reduce competing work, correct an inefficient query, address memory pressure, or adjust storage capacity when the evidence supports it.
- Verify the application and database response, device latency, swap movement, and logs after the change.
- Document the cause, change, result, and any remaining risk before closing the incident.
A reliable high io wait linux fix is based on measurements before and after the change. Avoid rebooting or changing several kernel settings at once unless the incident response plan requires it; doing so can remove evidence and make the cause harder to confirm.
Prevent recurring Linux I/O bottlenecks
- Alert on storage latency, queue depth, throughput, and provider-specific throttling metrics, not only CPU usage.
- Track memory pressure and sustained swap-in or swap-out activity alongside database and application health.
- Schedule backups, index maintenance, and heavy reports so they do not collide with peak production load.
- Keep filesystem capacity, inodes, and log rotation under monitoring.
- Record normal baselines for each server and storage tier so incident values have context.
- Test kernel or storage tuning changes on a representative workload and keep a rollback path.
When to bring in Linux operations support
Recurring freezes can involve several layers at once: Linux memory management, storage, a database, a cloud volume, and application behavior. If the team is spending time repeating the same incident response, OS Assistance can help investigate the cause and document a safer operating plan.
Emergency Linux support
For an active production incident, request emergency Linux support. The $199 emergency plan includes a 1-hour response SLA. The SLA covers response, not guaranteed resolution time; incident duration depends on scope and external dependencies.
Linux Care for ongoing operations
Linux Care is $4,000 per month for unlimited approved Linux servers, with one active workstream at a time. Requests are triaged and a plan is shared within 24 hours during weekday service hours. The current workstream is completed and documented before the next begins; complex work can span multiple business days depending on scope, access, maintenance windows, and dependencies. Discuss Linux Care with OS Assistance.
Frequently asked questions
What does high I/O wait mean on Linux?
It means CPUs were idle while I/O was outstanding during the sample period. It is a useful signal to investigate storage or a related wait, but it does not prove that one disk is saturated or identify the cause by itself.
What is the first step in a high io wait linux fix?
Capture repeated vmstat and iostat samples while the issue is happening. Compare wait, blocked tasks, swap activity, device latency, and queue size; then correlate those values with processes, logs, and cloud metrics. That evidence gives the high io wait linux fix a clear starting point.
Does 100% disk utilization always mean the device is saturated?
No. The meaning of %util depends on the device and its ability to handle concurrent requests. Compare latency, queue depth, throughput, and provider limits with a healthy baseline.
Does high swap usage mean the server is swap-thrashing?
No. Used swap can contain pages that are not active. Look for sustained swap-in or swap-out activity during the slowdown and correlate it with memory pressure and application latency.
Should I set swappiness to 10?
Not as a default fix. Measure memory pressure and test any swappiness change against the workload. Lowering it does not create RAM and may shift the problem rather than resolve it.
Can Linux Care cover recurring storage and server issues?
Linux Care covers unlimited approved Linux servers for $4,000 per month, with one active workstream at a time. Submit requests as issues arise; the team sequences work and documents each delivery.
