ファイルごとのLinux IO監視?


29

CentOSでファイルごとのディスクIOを監視するユーティリティまたはプロセスに興味があります。

Win2008では、resmonユーティリティはこのタイプのドリルダウンを許可しますが、私が見つけたLinuxユーティリティ(iostat、iotop、dstat、nmon)はどれもこれを行いません。

データベースサーバーのIOボトルネックを監視することに興味があります。MSSQLでは、どのファイル/ファイルスペースが最も激しくヒットしているかを知ることが有益な診断であることがわかりました。


2
たぶんLinuxのパフォーマンス分析とツール:SCaLE 11xでのBrendan Greggの講演はあなたを助けます。スライド72/115を参照してください。
クリスチャンシウピトゥ

1
これが可能な場合、ほとんどのファイルはページキャッシュにマップされるので、ページキャッシュにあるバイトとディスクにあるバイトに応じて番号がいたるところにあることに注意してください。
マシューイフェ

@Mattしかし、実用的な答えで!
ewwhite

回答:


18

SystemTapはおそらく最良のオプションです。

iotime.stpの例からの出力は次のようになります。

825946 3364 (NetworkManager) access /sys/class/net/eth0/carrier read: 8190 write: 0
825955 3364 (NetworkManager) iotime /sys/class/net/eth0/carrier time: 9
[...]
117061 2460 (pcscd) access /dev/bus/usb/003/001 read: 43 write: 0
117065 2460 (pcscd) iotime /dev/bus/usb/003/001 time: 7
[...]
3973737 2886 (sendmail) access /proc/loadavg read: 4096 write: 0
3973744 2886 (sendmail) iotime /proc/loadavg time: 11

短所(学習曲線を除く)は、kernel-debugをインストールする必要があることです。これは、本番システムでは不可能な場合があります。ただし、開発システムでモジュールをコンパイルし、実稼働システムでその.koを実行するクロスインストルメンテーションに頼ることができます。

または、短気な場合は、初心者ガイドの第4章「有用なSystemTapスクリプト」を参照してください。


17

SystemTap *スクリプト:

#!/usr/bin/env stap
#
# Monitor the I/O of a program.
#
# Usage:
#   ./monitor-io.stp name-of-the-program

global program_name = @1

probe begin {
  printf("%5s %1s %6s %7s %s\n",
         "PID", "D", "BYTES", "us", "FILE")
}

probe vfs.read.return, vfs.write.return {
  # skip other programs
  if (execname() != program_name)
    next

  if (devname=="N/A")
    next

  time_delta = gettimeofday_us() - @entry(gettimeofday_us())
  direction = name == "vfs.read" ? "R" : "W"

  # If you want only the filename, use
  // filename = kernel_string($file->f_path->dentry->d_name->name)
  # If you want only the path from the mountpoint, use
  // filename = devname . "," . reverse_path_walk($file->f_path->dentry)
  # If you want the full path, use
  filename = task_dentry_path(task_current(),
                              $file->f_path->dentry,
                              $file->f_path->mnt)

  printf("%5d %1s %6d %7d %s\n",
         pid(), direction, $return, time_delta, filename)
}

出力は次のようになります。

[root@sl6 ~]# ./monitor-io.stp cat
PID D  BYTES      us FILE
3117 R    224       2 /lib/ld-2.12.so
3117 R    512       3 /lib/libc-2.12.so
3117 R  17989     700 /usr/share/doc/grub-0.97/COPYING
3117 R      0       3 /usr/share/doc/grub-0.97/COPYING

または、マウントポイントからのパスのみを表示することを選択した場合:

[root@f19 ~]# ./monitor-io.stp cat
  PID D  BYTES      us FILE
26207 R    392       4 vda3,usr/lib64/ld-2.17.so
26207 R    832       3 vda3,usr/lib64/libc-2.17.so
26207 R   1758       4 vda3,etc/passwd
26207 R      0       1 vda3,etc/passwd
26208 R    392       3 vda3,usr/lib64/ld-2.17.so
26208 R    832       3 vda3,usr/lib64/libc-2.17.so
26208 R  35147      16 vdb7,ciupicri/doc/grub2-2.00/COPYING
26208 R      0       2 vdb7,ciupicri/doc/grub2-2.00/COPYING

[root@f19 ~]# mount | grep -E '(vda3|vdb7)'
/dev/vda3 on / type ext4 (rw,relatime,seclabel,data=ordered)
/dev/vdb7 on /mnt/mnt1/mnt11/data type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

制限/バグ:

  • mmapベースのI / Oが原因で表示されないdevnameです"N/A"
  • 上のファイルtmpfsのはので、表示されませんdevnameです"N/A"
  • 読み取りがキャッシュからであるか、書き込みがバッファからであるかは関係ありません

Matthew Ifeのプログラムの結果:

  • 以下のためのmmaptestプライベート:

     PID D  BYTES      us FILE
    3140 R    392       5 vda3,usr/lib64/ld-2.17.so
    3140 R    832       5 vda3,usr/lib64/libc-2.17.so
    3140 W     23       9 N/A,3
    3140 W     23       4 N/A,3
    3140 W     17       3 N/A,3
    3140 W     17     118 N/A,3
    3140 W     17     125 N/A,3
    
  • 以下のためmmaptest共有:

     PID D  BYTES      us FILE
    3168 R    392       3 vda3,usr/lib64/ld-2.17.so
    3168 R    832       3 vda3,usr/lib64/libc-2.17.so
    3168 W     23       7 N/A,3
    3168 W     23       2 N/A,3
    3168 W     17       2 N/A,3
    3168 W     17      98 N/A,3
    
  • 以下のためのdiotest(ダイレクトI / O):

     PID D  BYTES      us FILE
    3178 R    392       2 vda3,usr/lib64/ld-2.17.so
    3178 R    832       3 vda3,usr/lib64/libc-2.17.so
    3178 W     16       6 N/A,3
    3178 W 1048576     509 vda3,var/tmp/test_dio.dat
    3178 R 1048576     244 vda3,var/tmp/test_dio.dat
    3178 W     16      25 N/A,3
    

* RHEL 6または同等のクイックセットアップ手順:yum install systemtapおよびdebuginfo-install kernel


それはそこにかなり印象的なシステムタップです。その汎用性の優れたデモンストレーション。
マシューイフェ

これは、ダイレクトI / Oと非同期I / Oを測定しますか?(posixではなくio_submitを使用)
マシューイフェ

@Mlfe:ありがとう!サイドノートとして、スクリプトを書いている間にpvの小さなバグとSystemTapの別のバグ(task_dentry_path)を発見することができました:-)そのI / Oについてはわかりませんが、コマンドまたはサンプルプログラム。たとえば、Pythonを使用してmmapをテストしました。dd iflag=direct oflag=direct現れます。
クリスティアンシウピトゥ

2
mmapのためにこれを試してみてください:gist.github.com/anonymous/7014284私はプライベートマッピングを賭けているの測定が、共有のものがあるされていません。..
マシュー・イフェ

2
直接IOテストは次のとおり
Matthew Ife

9

あなたは実際blktraceにこれに使用したいと思うでしょう。Seekwatcherおよびblktraceを使用したLinux IOの視覚化を参照してください。

サンプルの1つをすぐに投稿できるかどうかを確認します。


編集:

Linuxの配布については言及していませんが、RHELのようなシステムを使用している場合、これはLinuxまたはSystem Tapでのdtraceスクリプトに適したケースかもしれません。


2
ありがたいことに、ポイントに非常に近いですが、詳細なブロックレイヤー情報を提供します。VFS抽象化レイヤーで動作するものが必要です。
-GioMac

これを実行するために、いくつかのsystemtapスクリプトを試行し始めました。サーバーがクラッシュしたため失敗しました。この情報は、SolarisのDtraceで入手できます。今日はLinuxを使ってみます。
ewwhite

4

私が知っている唯一のツールは、ファイルごとにI / Oアクティビティを監視できますinotifywatch。これはinotify-toolsパッケージの一部です。残念ながら、操作カウントのみを提供します。


4

iotopを使用して、高IOに寄与するプロセスのPIDを取得します

生成したPIDに対してstraceを実行すると、特定のプロセスがアクセスしているファイルが表示されます

strace -f -p $PID -e trace=open,read,write

straceは、syscallsおよびアクセスされたファイルに関する情報を提供します。使用状況の解析および統計情報の取得は非常に困難です
...-GioMac

1
これを試してみようと思った。ALOTのデータを生成します。ctrl + cを押すとプロセスがクラッシュする可能性があります。かなり危険なようです。
マット


2

私はあなたが間違った質問をしたかもしれないと主張します。I / Oのボトルネックを探している場合は、ディスクで何が起こっているかを確認することも同様に重要です。dbは、特に少数のスピンドルしかない場合に、スループットを大幅に低下させる可能性があるランダムI / Oを行うことで有名です。

より興味深いのは、ディスク自体の待ち時間が長いかどうかを確認することです。これを行うには、collectlコマンドで「collectl -sD」コマンドを使用します。これにより、個々のディスクパフォ​​ーマンスの統計情報が表示されます。--homeは、トップライクなユーティリティに変換します。多数のディスクが関係している場合は、colmux:colmux -command "-sD"を介して実行すると、複数のシステム間でも、選択した列でソートできます。


私はディスクの観点からあなたに反対しません。いくつかの洞察を得ることができるのは、データベースファイルスペースがデータ、インデックス、ログなどのパーティションに使用されているが、リソースが限られている場合は共有ディスクにマウントされている場合です(開発サーバーなど)。理想的には、これらの各ファイルスペースは別々のボリューム上にあるため、ディスクの観点からIOを調べることで十分です。これが、すべての監視ユーティリティがファイルベースではなくディスクである理由です。
ケルマット

それは正しい質問です。目標は「このI / Oがすべて発生しているテーブルはどれか」を把握することであり、ほとんどのデータベースではテーブルは1つ以上のファイルです。どのディスクにも多くのファイルが格納されることになりますが、どのディスクがホットスポットであるかを判断することは、有用なデータベースチューニング入力です。
グレッグスミス

2

ブロックデバイスごと(/ proc / diskstats経由)およびプロセスごと(ioアカウンティング/proc/$PID/ioまたはtaskstats経由)にI / Oを監視できますが、ファイルごとにI / O を行う方法がわかりません。


0

inotifyがこれを解決する可能性があります。

inotify APIは、ファイルシステムイベントを監視するためのメカニズムを提供します。Inotifyは、個々のファイルを監視したり、ディレクトリを監視したりするために使用できます。ディレクトリが監視されると、inotifyはディレクトリ自体とディレクトリ内のファイルのイベントを返します。

inotifyを使用したファイルシステムアクティビティの監視

inotifyリファレンス


これはファイルに対して行われた呼び出しを提供するかもしれませんが、pidが何をしたか、書き込みがどれだけ大きいか、どこで、どのくらい時間がかかったかを発見するのに役立つものはほとんどありません。
マシューイフェ

質問はプロセスについては尋ねません(おそらくのような他の手段によって発見される可能性がありますlsof
Gert van den Berg

0

ここの回答には多くの良い情報がありますが、実際に適用できるかどうか疑問に思っていますか?

常に書き込まれている数十ギガバイトのファイルについて話している場合、それらが常に追加されるログファイルまたは同様のもの(この場合は単にファイルサイズを監視する)でない限り、ファイルはmmapされている可能性が最も高い。その場合、最良の答えは、ほとんどのソリューションを見ることをやめることです。他の提案された解決策について最初に尋ねるべきことは、「mmapで動作します」です。ほとんどの場合は機能しませんが、ファイルを監視するのではなく、ブロックデバイスを監視するように問題を解決できる場合があります。

プログラムがmmapされたファイルからページを要求するとき、それは仮想メモリ内の場所を参照しているだけです。そのページは既にメモリにある場合とない場合があります。そうでない場合は、ページフォールトが生成され、ディスクからページが読み込まれますが、特定のアプリケーションプロセスや特定のファイルに簡単に結び付けられない仮想メモリシステム内で発生します。同様に、フラグに応じてアプリがmmapされたページを更新すると、ディスクへの即時書き込みがトリガーされない場合があり、場合によってはディスクにまったく行かない場合があります(ただし、おそらく最後のものは興味のある場合ではありません)に)。

mmapされたファイルについて考えられる最善の方法は、実行可能な場合、対象の各ファイルを個別のデバイスに配置し、デバイスの統計情報を使用して使用情報を収集することです。これにはlvmパーティションを使用できます。新しいブロックデバイスを作成しないため、バインドマウントは機能しません。

ファイルを別のブロックデバイスに配置したら、/ sys / block / *または/ proc / diskstatsから統計情報を取得できます

これを実稼働サーバーに導入するのはあまりにも混乱を招くかもしれませんが、おそらくそれを利用することができます。

ファイルがマップされていない場合は、はい、ここで他のソリューションのいずれかを選択できます。


注意深く読んでください、ブロックレベルの統計は必要ありません:)
GioMac

正しい、しかしあなたが求めている種類の統計は、mmapファイルでは不可能です。そのため、もしあなたがそれに立ち向かうなら、これは、デバイスごとに1つのファイルを使用して、ファイルに関する統計を取得し、デバイスの統計。
mc0e

-1

私は最近collectlをいじくり回していました。これは素晴らしいツールで、インストールがとても簡単です。最も興味深いのは、IOボトルネックの原因となっているプロセスを見つけることができることです。Collectlの使用を読むことをお勧めします 。役立つかもしれません。


1
collectlはファイルごとに監視せず、プロセスごとに動作します
グレッグスミス


-2

iotopは、IOのボトルネックを特定するためのLinux上で最高のツールの1つだと思います。


3
-1 iotopはファイルごとに監視せず、プロセスごとに動作します
-dyasny
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.