web-dev-qa-db-ja.com

ディスクの測定IO実行中のプロセスの待ち時間

ヒストグラムを作成するために、実行中のプロセスのディスクIOレイテンシを測定しようとしています。

これを提供するオペレーティングシステムでDTraceを使用してこれを行うことはできますが（例： このJoyentの論文 のように）、私のアプリケーションはLinuxで実行されています。私の最初の考えはperfを試すことでした、そして私はカウンターを得ることができます、しかし私は時間デルタを得る方法を見つけることができません。 straceで時間デルタを取得できます（例：strace -e read -T）、しかし、トレースをディスクに制限できるかどうかはわかりませんIO（このシステムにはビジーなネットワークインターフェイスもあります）。

Linuxでこれを行う方法はありますか？

linuxstraceperf-eventdtrace
7
ajduff574

これは実際には複雑です。しかし、ヒントがあります：

  • SystemTapについて学んでください。これはDTraceのLinuxアナログです。同様のタスクのサンプルスクリプトもあると思います。

  • 学ぶ blktrace 。理論的には、その出力を解析できる可能性があります。これは、応答時間プログラムがread()を取得するよりも、デバイスの待ち時間（サービス時間）が長くなります。

はいstraceはすべてをトレースし（-eフィルターを使用する場合でもすべてのシステムコール）、サーバーをロードし、プロセスをかなり遅くするため、適切ではない可能性があります。 Perfは非常にあいまいなツールであり、出力を理解したと思う瞬間があるかもしれませんが、実際には理解していません。その機能セットはカーネルのバージョンに大きく依存しています。基本的におよび現在perfは、CPU時間（サイクル）の測定に適していますが、[まだ]応答時間の測定には適していません（実際に必要です）。彼らはそれを容易にするために何かを実装したいと聞いたので、ごく最近の開発カーネルでは何かがあるかもしれません。 （さらに調査する場合は、perfスクリプト（perf script -l）も確認してください。）

  • ftraceから何かを取得できる可能性があります。この記事を読んでください http://lwn.net/Articles/370423/ （そしてこれは イントロ です。）私が見ることができるように、pidと関数によってトレースを制限することができます。次に、sys_readのようなものでトレースします。私はあなたのためにこれを例として試しました：

    # mount -t debugfs debugfs /sys/kernel/debug # if it's not already mounted
# cd /sys/kernel/debug/tracing
# echo $$ > set_ftrace_pid  # pid of process to trace
# echo sys_read sys_write > set_ftrace_filter
# echo function_graph > current_tracer
# head trace

# tracer: function_graph
#
# CPU  DURATION                  FUNCTION CALLS
# |     |   |                     |   |   |   |
 0)   8.235 us    |  sys_write();
 0)   3.393 us    |  sys_write();
 0) ! 459859.3 us |  sys_read();
 0)   6.289 us    |  sys_write();
 0)   8.773 us    |  sys_write();
 0) ! 1576469 us |  sys_read();
7
catpnosis

ブロックデバイスへの「読み取り」または「書き込み」呼び出しの数のみに関心がある場合 これはRedHatのSOPそれを決定するための です。

ブロックダンプ機能とスクリプトのビットを使用して、プロセスが生成しているI/Oアクションに関する高レベルの概要を収集できます。これを行うには、以下を完了します。

システムロギングを短期間無効にします（データキャプチャの邪魔にならないようにします）。

＃service syslog stop＃echo 1>/proc/sys/vm/block_dump

Syslog（またはそれを使用している場合はrsyslog）を再度有効にしてから、iowaitの高い問題が発生するまで待ち、ブロックダンプを無効にします。

＃service syslog start＃echo 0>/proc/sys/vm/block_dump

次のコマンドを使用して、特定のプロセスによって発行されているREAD/WRITE/dirtiedアクションのdmesg出力を解析します。

＃dmesg | awk '/（READ | WRITE | dirtied）/ {activity [$ 1] ++} END {for（x in activity）print x、activity [x]}' |並べ替え-nr -k 2,2 |頭-n10

kjournald（1425）：5984 kjournald（3681）：1269 pdflush（27301）：725 iostat（2913）：134 crond（26919）：61 crond（28985）：60 crond（7026）：54 sshd（28175）：50 sshd（ 15388）：50ノーチラス（24498）：46

上記の出力例は、ブロックダンプの実行中にREAD、WRITE、およびダーティ操作を発行した上位10個のプロセスを示しています。このデータを使用して、プロセスが発行している操作の数の概要を収集でき、単一のプロセスがiowaitに大きく貢献しているかどうかを判断するのに役立ちます。

プロセスごとのiowait統計を提供し、スクリプトの一部として実行できるatopやiotopなどのコマンドラインツールもいくつかあります（つまり、特定のPIDに対して単一の反復を実行できるバッチモードがあります）。

編集：できるようにさらに調査を行う / proc/$ pid/statからプロセスごとのiowaitを取得 （検索「集約されたブロックI/O遅延」の場合）

2
Bratchley