Linuxデスクトップで非常に高いw_awaitを修正する方法は？
私のLinux（Debian sid）デスクトップは、ここ数週間で動きが鈍くなり始めました。調べてみると、次のことがわかりました。
- RAMの不足はありません。システムは通常4Gの半分しか使用せず、キャッシュとバッファーをカウントする場合でも1G以上の空き容量があります。
- 停滞はファイルアクセスに関連しています。たとえば、KMailでフォルダを開くと、ミニフリーズが発生します。
- 動作が遅くなると、CPUはiowaitで多くの時間を費やしています。
さらに掘り下げると、次のようなものが見つかりました。
$ iostat -x -d /dev/sda
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.05 7.90 3.14 2.41 23.27 40.94 23.11 12.02 2163.14 57.59 4906.16 31.58 17.55
私が正しく理解していれば、w_awaitの値（ほぼ5000）は非常に高く、結果としてawaitの値（r_awaitとw_awaitの平均？）は非常に高く、それ以外は正常です。
過度の停滞時にiotopを見ると、通常はすべてゼロが表示され、kjournald、flush、場合によっては期待するプロセス（KMailなど）が99.9％iowaitで点滅します。
このシステムは数年間「ローリングディストリビューション」として使用されており、すべてのファイルシステムはext3です。
ああ、そしてもちろん：スワップは定義されていますが（システムに常にマウントされている唯一のディスクです）、ほとんど使用されていません（私が言ったように、4Gはほとんど使い果たされていません）。
私がdmesgで見た唯一のエラーは、120秒以上ブロックされたプロセスの叫びです（トラブルのピークで-再起動後の最初の数分で）。主にsyslog。ディスク障害の兆候は他にないようです（smartctlは、ディスクの気流が加熱されたずっと前の時間を除いて、すべてが常に正常であると言っています）。
私はLinux3.2を使用しています。 2.6.38に戻そうとしましたが、役に立ちませんでした。
ディスクですか？ファイルシステムがおかしくなりましたか？これ以上何を確認できますか？
あなたの場合、あなたはハードドライブの交換がそれを修正したと言います。それは良い。しかし、私の経験では、最近ラップトップでしか見られませんでしたが、これはほとんどの場合マザーボードレベルのSATAハードウェアの問題であり、ラップトップの場合は修復できませんでした。ドライブを交換しても効果はありませんでした。ラップトップでも同様の症状が見られただけなので、ドライブを交換してみることをお勧めします。それでも問題が解決しない場合は、マザーボードである可能性があります。
ちなみに、OSを何度か再インストールして、グリッチ（Windowsと使用したすべてのLinuxバージョンの両方で発生）を回避したと思いましたが、しばらく使用した後、戻ってきたようで、そこにあると思いました。ハードウェア/チップセットのグリッチに対する熱コンポーネントでした。
（これはすべて、カーネルを切り替えただけでなく、カーネルドライバーに不具合があることを前提としていますが、さまざまなカーネルレベルを試したところ、これは私の最近の問題に非常に明確に対応しています。）
それが価値があることについて、これを見つけた人のために、私は要約したいと思います。
結論：それは確かにディスクだったようです。私はそれを交換しました、そして、物事は正常に戻っているようです。
そこへ行く途中で、2つの興味深い（そして安価な）小切手を見つけました。
1）問題が自分のOSセットアップにないことを確認するために、ライブCDからディスクアクティビティを生成しようとしました。疑われるように、I/Oはひどいものでした。
2）問題がファイルシステムだけにあるのではないことを確認するために、ディスクの空き領域を使用して、新しいファイルシステムを作成しようとしました。これはひどく遅くなり、さらに、それが終了した後、OSはディスクから「停止」実行可能ファイルを読み取ることさえできませんでした。
3番目のテストは、実際、ウォーレンが提案したより高価なテストでした。ディスクの交換です。新しいディスクは問題ないようです。