デバイスごとのIOwaitを測定する方法は？
NFS経由でホームディレクトリをエクスポートするサーバーがあります。それらはソフトウェアRAID1（/ dev/sdbおよび/ dev/sdc）にあり、OSは/ dev/sdaにあります。 topおよびsarによって報告された%iowaitが比較的高いことに気付きました（他のサーバーと比較してください）。値の範囲は5〜10％で、他のサーバー（これよりも負荷が高い）は0〜1％と同じです。 %iowaitが12％を超える値に達すると、いわゆるユーザーエクスペリエンスが低下します。その後、遅延が発生します。
ログにドライブエラーはありません。試行錯誤的な方法でドライブを操作することは避けたいです。
どのデバイス（/ dev/sda、/ dev/sdbまたは/ dev/sdc）がボトルネックになっているのかを知るにはどうすればよいですか？
ありがとう！
編集：私はUbuntu 9.10を使用しており、すでにiostatがインストールされています。私はNFS関連の問題には興味がありませんが、どのデバイスを見つけてシステムの速度を低下させるかについては、もっと知りたいです。 NFSがロードされていません。32スレッドが利用可能です。
grep th /proc/net/rpc/nfsd
th 32 0 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000
Edit2：iostat -x 1の出力の一部を次に示します（ここでいくつかのルールに違反していないことを願っています）：
avg-cpu: %user %Nice %system %iowait %steal %idle
45.21 0.00 0.12 4.09 0.00 50.58
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 21.00 0.00 368.00 0.00 17.52 0.17 8.10 6.67 14.00
sdb 0.00 6.00 0.00 6.00 0.00 96.00 16.00 0.00 0.00 0.00 0.00
sdc 0.00 6.00 0.00 6.00 0.00 96.00 16.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 21.00 0.00 368.00 0.00 17.52 0.17 8.10 6.67 14.00
dm-2 0.00 0.00 0.00 12.00 0.00 96.00 8.00 0.00 0.00 0.00 0.00
drbd2 0.00 0.00 0.00 12.00 0.00 96.00 8.00 5.23 99.17 65.83 79.00
avg-cpu: %user %Nice %system %iowait %steal %idle
45.53 0.00 0.24 6.56 0.00 47.68
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 1.00 23.00 2.00 424.00 24.00 17.92 0.23 9.20 8.80 22.00
sdb 0.00 32.00 0.00 10.00 0.00 336.00 33.60 0.01 1.00 1.00 1.00
sdc 0.00 32.00 0.00 10.00 0.00 336.00 33.60 0.01 1.00 1.00 1.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 23.00 0.00 424.00 0.00 18.43 0.20 8.70 8.70 20.00
dm-2 0.00 0.00 0.00 44.00 0.00 352.00 8.00 0.30 6.82 0.45 2.00
drbd2 0.00 0.00 0.00 44.00 0.00 352.00 8.00 12.72 80.68 22.73 100.00
avg-cpu: %user %Nice %system %iowait %steal %idle
44.11 0.00 1.19 10.46 0.00 44.23
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 637.00 19.00 16.00 432.00 5208.00 161.14 0.34 9.71 6.29 22.00
sdb 0.00 31.00 0.00 13.00 0.00 352.00 27.08 0.00 0.00 0.00 0.00
sdc 0.00 31.00 0.00 13.00 0.00 352.00 27.08 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 20.00 651.00 456.00 5208.00 8.44 13.14 19.58 0.33 22.00
dm-2 0.00 0.00 0.00 42.00 0.00 336.00 8.00 0.01 0.24 0.24 1.00
drbd2 0.00 0.00 0.00 42.00 0.00 336.00 8.00 4.73 73.57 18.57 78.00
avg-cpu: %user %Nice %system %iowait %steal %idle
46.80 0.00 0.12 1.81 0.00 51.27
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 0.00 16.00 0.00 240.00 0.00 15.00 0.14 8.75 8.12 13.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
調べるべき最も関連する列は何ですか？不健康と見なされる値は何ですか？ awaitと%utilが私が探しているものだと思います。私の意見では、dm-1がボトルネックです（これはDRBDリソースメタデータです）。
二重の感謝！
Edit3：これが私の設定です：
sda = OS、RAIDなし。デバイスdm-0およびdm-1は、後者がDRBDリソースのメタデータデバイスであるため、その上にあります（以下を参照）。 dm-0とdm-1はどちらもLVMボリュームです。 drbd2 = dm-2 = sdb + sdc->これは、NFS経由でユーザーのホームディレクトリを提供するRAID1デバイスです。これはボトルネックではないと思います。ここにLVMボリュームはありません。
iostat -x 1？
その答えをさらに拡張する必要があると言われましたが、まだ何を追加すればよいかわかりません。どのディストリビューションを使用しているかはわからないので、iostatをまだインストールしていない場合は、iostatをインストールする方法を紹介することはできません。しかし、それはあなたが求めていることだと思います。
編集：iostatの出力を見てうれしい！現時点では、sd [ab]デバイスの数値はほぼ同じであり、RAID-1の場合と同じであり、どちらも飽和していません。 sdcでもありません。ただし、drbd2は、これは何に使用され、サーバー全体のパフォーマンスにどのように影響しますか？
編集2：何を提案すればよいかわからない。 drbd2が「NFS経由でユーザーのホームディレクトリを提供する」ことを認め、NFSサーバーのレイテンシの問題があると言います。 drbd2がボトルネックデバイスであるとかなり説得力のあるiostat出力を生成します。次に、「私の意見では、dm-1がボトルネックであり、「[drbd2]はボトルネックではないと思います」」と言います。 drbd2がボトルネックであるという仮説に反する証拠がどのようなものであるかは明確ではありませんが、それを見るといいでしょう。
/ dev/sdbと/ dev/sdcの両方に、非常に近い「待機」因子数があります。/dev/sdaにはいくつか大きな数字がありますが、それに含まれていないRAIDパフォーマンスにどのように影響しますか？ところで、ミラーリングにLVMを使用しますか？
したがって、iostatを読むと、どのドライブにIO問題があるかを絞り込むことができますが、IO問題の原因となっているアプリケーションを追跡すると、実際に状況を改善するのにはるかに役立ちます。そのiotopは素晴らしいです：
これは頻繁に使用されるNFSサーバーですか？ NFSがボトルネックであるかどうかを確認する良い方法は、NFSプロセスがどのように実行されているか、およびどれかが待機状態にあるかどうかを確認することです。
grep th/proc/net/rpc/nfsd
th 128 239329954 363444.325 111999.649 51847.080 12906.574 38391.554 25029.724 24115.236 24502.647 0.000 520794.933
最初の数値は要求の処理に使用できるスレッドの数で、2番目の数値はすべてのスレッドが必要になった回数です。残りの10の数値は、スレッドの特定の部分がビジー状態である秒数を示すヒストグラムであり、スレッドの10％未満で始まり、90％を超えるスレッドで終わります。最後のいくつかの数値がかなりの時間を蓄積している場合は、サーバーにおそらくより多くのスレッドが必要です。
/etc/rc.d/init.d/nfsのRPCNFSDCOUNT = 16を変更して、サーバーが使用するスレッドの数を16に増やします。
詳しくは http://billharlan.com/pub/papers/NFS_for_clusters.html の「Server Threads」の見出しをご覧ください。