iostat を使用して Linux ハードディスクの IO パフォーマンスを表示する方法

TOP 観察: IO 待機に占められる CPU 時間の割合。30% を超えると、IO の負荷が高くなります。次に、iostat -x 1 10 を使用します。

[ルート@コントローラー ~]#iostat -d -k 1 10
デバイス: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
19.00 0.00 112.00 0 112
sda1 0.00 0.00 0.00 0 0
sda2 0.00 0.00 0.00 0 0
sda3 0.00 0.00 0.00 0 0
sda4 0.00 0.00 0.00 0 0
sda5 3.00 0.00 16.00 0 16
sda6 0.00 0.00 0.00 0 0
sda7 16.00 0.00 96.00 0 96

tps: デバイスの 1 秒あたりの送信回数。1 回の送信は「1 回の I/O 要求」を意味します。

• kB_read/s: デバイスから1秒あたりに読み取られるデータの量
• kB_wrtn/s: 1秒あたりにデバイスに書き込まれるデータの量
• kB_read: 読み取られたデータの合計量
• kB_wrtn: 書き込まれたデータの総量
  

詳細情報を取得するには -x を使用してください

詳細情報を取得するには -x を使用してください

デバイスの使用状況 (%util) と応答時間 (await) を表示します。

[ルート@コントローラー ~]#iostat -d -x -k 1 10
デバイス: rrqm/s wrqm/sr/sw/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
0.00 22.00 0.00 18.00 0.00 160.00 17.78 0.07 3.78 3.78 6.80
sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda3 0.00 15.00 0.00 2.00 0.00 68.00 68.00 0.01 6.50 6.50 1.30
sda4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sda7 0.00 7.00 0.00 16.00 0.00 92.00 11.50 0.06 3.44 3.44 5.50

• rrqm/s: 1 秒あたりのマージ読み取り操作の数。つまり、delta(rmerge)/s
• wrqm/s: 1 秒あたりのマージ書き込み操作の数。つまり、delta(wmerge)/s
• r/s: 1 秒あたりに完了した読み取り I/O デバイスの数。それはデルタ(リオ)/sです
• w/s: 1 秒あたりに完了した書き込み I/O デバイス操作の数。つまり、デルタ(wio)/s
• rsec/s: 1 秒あたりに読み取られるセクター数。つまり、delta(rsect)/s
• wsec/s: 1 秒あたりに書き込まれるセクター数。つまり、delta(wsect)/s
• rkB/s: 1 秒あたりに読み取られる K バイト。各セクター サイズは 512 バイトなので、rsect/s の半分になります。 （計算が必要です）
• wkB/s: 1 秒あたりに書き込まれる K バイト数。 wsect/s の半分です。 （計算が必要）
• avgrq-sz: デバイス I/O 操作あたりの平均データ サイズ (セクター)。デルタ(rsect+wsect)/デルタ(rio+wio)
• avgqu-sz: 平均 I/O キューの長さ。つまり、delta(aveq)/s/1000 です (aveq はミリ秒単位であるため)。
• await: 各デバイス I/O 操作の平均待機時間 (ミリ秒単位)。つまり、デルタ(ruse+wuse)/デルタ(rio+wio)
• svctm: 各デバイス I/O 操作の平均サービス時間 (ミリ秒単位)。つまり、デルタ(使用)/デルタ(リオ+wio)
• %util: 1 秒あたりの何パーセントが I/O 操作に使用されているか、または 1 秒あたりに I/O キューが空でない時間の長さ。つまり、デルタ(使用)/秒/1000（使用単位はミリ秒であるため）

%util が 100% に近い場合、生成される I/O 要求が多すぎること、I/O システムがすでに完全にロードされていること、およびディスクにボトルネックがある可能性があることを意味します。

アイドルが 70% 未満の場合、IO 圧力は比較的高く、一般的に読み取り速度の待機が多くなります。

vmstatを使用してbパラメータ（）とwaパラメータ（）を表示することもできます。

参照することもできます

svctm は通常、await よりも小さくなります (同時に待機している要求の待機時間が繰り返しカウントされるため)。svctm のサイズは、通常、ディスク パフォーマンスに関連します。CPU/メモリ負荷も影響します。要求が多すぎると、間接的に svctm が増加します。待機のサイズは通常、サービス時間 (svctm) だけでなく、I/O キューの長さや I/O 要求の発行パターンによっても異なります。 svctm が await に近い場合、I/O の待機時間がほとんどないことを意味します。await が svctm よりはるかに大きい場合は、I/O キューが長すぎてアプリケーションの応答時間が遅いことを意味します。応答時間がユーザーの許容範囲を超える場合は、より高速なディスクの交換、カーネル エレベータ アルゴリズムの調整、アプリケーションの最適化、または CPU のアップグレードを検討できます。

キューの長さ (avgqu-sz) もシステム I/O 負荷を測定する指標として使用できますが、avgqu-sz は単位時間あたりの平均値であるため、瞬間的な I/O フラッドを反映することはできません。

他にも良い例があります。(I/O システムとスーパーマーケットの行列)

たとえば、スーパーでレジに並んでいるとき、どのレジカウンターに行くかをどのように決めますか？まず見るのは、列に並んでいる人の数です。5人の方が20人より早いですよね？人数を数えることに加えて、私たちは前に並んでいる人がどれだけ買ったかを見ることがよくあります。私たちの前に1週間分の食料を買っているおばさんがいたら、列を変えることを検討できます。もう一つはレジのスピードです。お金を数えることすらできない初心者に出会ったら、待たされることになります。また、タイミングも非常に重要です。5分前まで混雑していたレジカウンターが今は空いているかもしれません。このタイミングで支払いをするのはとても気持ちが良いものです。もちろん、この5分間で何をしたかの方が、列に並ぶことより有意義であることが前提です（でも、列に並ぶことより退屈なことは他に思い当たりません）。

I/O システムには、スーパーマーケットの行列との類似点も数多くあります。

• r/s+w/sは受取人の合計数に似ている
• 平均待ち行列の長さ (avgqu-sz) は、単位時間あたりの待ち行列内の平均人数に似ています。
• 平均サービス時間（SVCTM）はレジ係の回収速度とほぼ同じです
• 平均待ち時間（待機）は、1人あたりの平均待ち時間とほぼ同じです。
• 平均 I/O データ (avgrq-sz) は、各人が購入する物の平均量に似ています。
• I/O 操作率 (%util) は、レジに行列ができている時間の割合に似ています。

このデータを使用して、I/O 要求パターン、I/O 速度、応答時間を分析できます。

%util: 統計時間中のすべての IO 処理時間を合計統計時間で割った値。たとえば、統計間隔が 1 秒で、デバイスが 0.8 秒間 IO を処理し、0.2 秒間アイドル状態の場合、デバイスの %util = 0.8/1 = 80% となり、このパラメーターはデバイスのビジー状態を示します。通常、このパラメータが 100% の場合、デバイスがほぼ全容量で動作していることを意味します (もちろん、複数のディスクがある場合、%util が 100% であっても、ディスクの同時実行機能により、ディスク使用率が必ずしもボトルネックに達するとは限りません)。
）

プログラムを導入する際（リアルタイムでログをアップロードするプログラムをテストしました）、システムの効率的な動作を確保するために、システムの CPU、メモリ、IO などを考慮する必要があります。

プログラム自体が非常に小さなパケットを処理し、多くのイベントがあり、プレッシャーが高く、間隔がない場合、CPU リソースを大量に占有することになります。

メモリ キャッシュの代わりにディスク キャッシュを使用すると、ブレークポイントの再送信をサポートして、信頼性の高いデータ アップロードを確保できます。突然の停電が発生した場合でも、ディスク キャッシュに保存されているデータは回復後にアップロードされ、失われることはありません。ただし、ディスクの読み取りと書き込みの回数はそれに応じて増加します。データ量が比較的少ない場合、速度はまだ許容範囲内です。

以下は、他の人が書いたこのパラメータ出力の分析です。

# iostat -x 1
平均CPU: %user %nice %sys %idle
16.24 0.00 4.31 79.44
デバイス: rrqm/s wrqm/sr/sw/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
/dev/cciss/c0d0 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p1 0.00 44.90 1.02 27.55 8.16 579.59 4.08 289.80 20.57 22.35 78.21 5.00 14.29
/dev/cciss/c0d0p2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

上記の iostat 出力は、1 秒あたり 28.57 回のデバイス I/O 操作があることを示しています。合計 IO (io)/s = r/s (読み取り) + w/s (書き込み) = 1.02 + 27.55 = 28.57 (回/秒)、そのうち書き込み操作が大部分を占めています (w:r=27:1)。

平均すると、各デバイスの I/O 操作は完了するのに 5 ミリ秒しかかかりませんが、各 I/O 要求は 78 ミリ秒待機する必要があります。なぜでしょうか? I/O 要求が多すぎるためです (1 秒あたり約 29 件)。これらの要求が同時に発行されると仮定すると、平均待機時間は次のように計算できます。

平均待ち時間 = 単一 I/O サービス時間 * (1 + 2 + ... + リクエストの総数 - 1) / リクエストの総数

上記の例に適用すると、平均待機時間 = 5ms*(1+2+…+28)/29=70ms となり、これは iostat によって示された平均待機時間 78ms に非常に近くなります。これは、I/O が同時に開始されたことを示します。

1 秒あたりに発行される I/O 要求は多数 (約 29) ありますが、平均キューは長くありません (約 2 のみ)。これは、これらの 29 個の要求の到着が均一ではなく、I/O がほとんどの時間アイドル状態であることを示しています。

1 秒間に 14.29% の時間、I/O キューにリクエストが存在し、これは 85.71% の時間、I/O システムが何もしていないことを意味します。29 個の I/O リクエストはすべて 142 ミリ秒以内に処理されます。

delta(ruse+wuse)/delta(io) =await=78.21=>delta(ruse+wuse)/s=78.21*delta(io)/s= 78.21*28.57=2232.8 であり、1 秒あたりの I/O 要求は合計 2232.8 ミリ秒待機する必要があることを示しています。したがって、平均キュー長は 2232.8ms/1000ms = 2.23 になるはずですが、iostat によって提供される平均キュー長 (avgqu-sz) は 22.35 です。なぜでしょうか? iostat にバグがあるため、avgqu-sz 値は 22.35 ではなく 2.23 になるはずです。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。