Member Avatar for blud
blud 82 Linux Reject

A lot of people have noticed that Redhat Enterprise had some io issues for Pentium 4 processors, this can usually be fixed by updating to the latest kernel and/or putting the following lines into your /etc/rc.d/ file:

echo 100 > /proc/sys/vm/inactive_clean_percent
echo 2 10 20 > /proc/sys/vm/pagecache

This has been said by redhat to be a preformance tweak however it has also saved a lot of people when thier box will randomly lock and thier iowait is at 100%

  • 1 Contributor
  • 0 Replies
  • 471 Views

Dani AI

Generated

As noted, a number of RHEL/Pentium‑4 installs saw extreme iowait. Below are practical, non‑invasive steps to diagnose the root cause and safer tuning alternatives you can apply and revert without risking data integrity.

Start by collecting short, repeatable traces so you can see whether the problem is saturation, a stuck device, or a pathological writeback burst:

vmstat 1 20
iostat -x 1 20
top -b -d 1 -n 20   # look for processes in "D" state and high %wa

Also check kernel messages and device health:

dmesg | egrep -i 'ata|sd|error|timeout'
smartctl -a /dev/sdX
hdparm -tT /dev/sdX

Common causes and quick experiments

  • Hardware/driver: timeouts and DMA falling back to PIO show in dmesg; bad drives show SMART errors.
  • Scheduler/queue depth: try the deadline or noop scheduler temporarily to see if latency improves.
  • VM writeback behavior: rather than one‑off rc.local echoes, use sysctl and /etc/sysctl.conf to persist controlled changes to vm.dirty_* settings; tune conservatively and observe.
  • Filesystem options: mounting with noatime or adjusting journal commit= values can reduce write bursts (know the durability tradeoffs).

Example quick change (non‑persistent) to test scheduler and VM behavior:

echo deadline > /sys/block/sdX/queue/scheduler
sysctl -w vm.dirty_background_ratio=5
sysctl -w vm.dirty_ratio=10

Cautions and next steps

  • Don’t blindly increase dirty limits; this can improve throughput at the cost of larger in‑memory writebacks and higher risk on crash.
  • If traces show device errors, replace the drive or controller before further tuning.
  • If the issue disappears on a newer kernel or with a different scheduler, chase the corresponding RHEL errata/driver update and consider an upstream kernel or vendor patch.

Prioritize trace → hardware check → conservative tuning → persistent change. If unsure, gather the above outputs before making permanent changes or opening a support case.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.