☰

実行中のプロセスのディスクIOレイテンシを測定する

tag-icon • tag-icon linux strace perf-event dtrace
実行中のプロセスのディスクIOレイテンシを測定する

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

DTraceが使えるOSであれば、これを使ってこれを行うことができます（例えば、このジョイエント紙) を使用していますが、アプリケーションは Linux で実行されています。最初に考えたのは を試すことでした。カウンターは取得できますが、時間差を取得する方法が見つかりません。 (例)perfを使用して時間差を取得することはできますが、トレース対象をディスク IO に制限できるかどうかはわかりません (このシステムにはビジーなネットワーク インターフェイスもあります)。stracestrace -e read -T

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

答え1

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

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

  • 学ぶブロックトレース理論的には、その出力を解析できるかもしれません。これは、デバイスのレイテンシ（サービス時間）よりも長くなります。反応時間プログラムに参加してくださいread()。

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

  • 何かが得られるかもしれませんトレースこの記事を読むhttp://lwn.net/Articles/370423/（そしてこれはイントロ) ご覧のとおり、pidと 関数で ftracing を制限し、 のようなものでトレースすることができます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();

答え2

ブロックデバイスへの「読み取り」または「書き込み」呼び出しの数のみに興味がある場合これはRed HatのSOPであり、。

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

システム ログを短時間無効にします (データ キャプチャの妨げにならないようにするため):

# サービス syslog 停止 # エコー 1 > /proc/sys/vm/block_dump

高い iowait の問題が発生するまで待機し、それが過ぎたら syslog (または rsyslog を使用している場合は rsyslog) を再度有効にして、ブロック ダンプを無効にします。

# サービス syslog 開始 # エコー 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]}'| sort -nr -k 2,2| head -n 10

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 nautilus(24498): 46

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

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

編集： さらに調査してみると、/proc/$pid/stat からプロセスごとの iowait を取得する(「集約ブロック I/O 遅延」を検索)

関連情報