CentOSでファイルごとのディスクIOを監視するユーティリティまたはプロセスに興味があります。
Win2008では、resmonユーティリティはこのタイプのドリルダウンを許可しますが、私が見つけたLinuxユーティリティ(iostat、iotop、dstat、nmon)はどれもこれを行いません。
データベースサーバーのIOボトルネックを監視することに興味があります。MSSQLでは、どのファイル/ファイルスペースが最も激しくヒットしているかを知ることが有益な診断であることがわかりました。
CentOSでファイルごとのディスクIOを監視するユーティリティまたはプロセスに興味があります。
Win2008では、resmonユーティリティはこのタイプのドリルダウンを許可しますが、私が見つけたLinuxユーティリティ(iostat、iotop、dstat、nmon)はどれもこれを行いません。
データベースサーバーのIOボトルネックを監視することに興味があります。MSSQLでは、どのファイル/ファイルスペースが最も激しくヒットしているかを知ることが有益な診断であることがわかりました。
回答:
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スクリプト」を参照してください。
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)
制限/バグ:
devname
です"N/A"
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
task_dentry_path
)を発見することができました:-)そのI / Oについてはわかりませんが、コマンドまたはサンプルプログラム。たとえば、Pythonを使用してmmapをテストしました。dd iflag=direct oflag=direct
現れます。
あなたは実際blktrace
にこれに使用したいと思うでしょう。Seekwatcherおよびblktraceを使用したLinux IOの視覚化を参照してください。
サンプルの1つをすぐに投稿できるかどうかを確認します。
編集:
Linuxの配布については言及していませんが、RHELのようなシステムを使用している場合、これはLinuxまたはSystem Tapでのdtraceスクリプトに適したケースかもしれません。
私が知っている唯一のツールは、ファイルごとにI / Oアクティビティを監視できますinotifywatch
。これはinotify-tools
パッケージの一部です。残念ながら、操作カウントのみを提供します。
iotopを使用して、高IOに寄与するプロセスのPIDを取得します
生成したPIDに対してstraceを実行すると、特定のプロセスがアクセスしているファイルが表示されます
strace -f -p $PID -e trace=open,read,write
私はあなたが間違った質問をしたかもしれないと主張します。I / Oのボトルネックを探している場合は、ディスクで何が起こっているかを確認することも同様に重要です。dbは、特に少数のスピンドルしかない場合に、スループットを大幅に低下させる可能性があるランダムI / Oを行うことで有名です。
より興味深いのは、ディスク自体の待ち時間が長いかどうかを確認することです。これを行うには、collectlコマンドで「collectl -sD」コマンドを使用します。これにより、個々のディスクパフォーマンスの統計情報が表示されます。--homeは、トップライクなユーティリティに変換します。多数のディスクが関係している場合は、colmux:colmux -command "-sD"を介して実行すると、複数のシステム間でも、選択した列でソートできます。
inotifyがこれを解決する可能性があります。
inotify APIは、ファイルシステムイベントを監視するためのメカニズムを提供します。Inotifyは、個々のファイルを監視したり、ディレクトリを監視したりするために使用できます。ディレクトリが監視されると、inotifyはディレクトリ自体とディレクトリ内のファイルのイベントを返します。
lsof
)
ここの回答には多くの良い情報がありますが、実際に適用できるかどうか疑問に思っていますか?
常に書き込まれている数十ギガバイトのファイルについて話している場合、それらが常に追加されるログファイルまたは同様のもの(この場合は単にファイルサイズを監視する)でない限り、ファイルはmmapされている可能性が最も高い。その場合、最良の答えは、ほとんどのソリューションを見ることをやめることです。他の提案された解決策について最初に尋ねるべきことは、「mmapで動作します」です。ほとんどの場合は機能しませんが、ファイルを監視するのではなく、ブロックデバイスを監視するように問題を解決できる場合があります。
プログラムがmmapされたファイルからページを要求するとき、それは仮想メモリ内の場所を参照しているだけです。そのページは既にメモリにある場合とない場合があります。そうでない場合は、ページフォールトが生成され、ディスクからページが読み込まれますが、特定のアプリケーションプロセスや特定のファイルに簡単に結び付けられない仮想メモリシステム内で発生します。同様に、フラグに応じてアプリがmmapされたページを更新すると、ディスクへの即時書き込みがトリガーされない場合があり、場合によってはディスクにまったく行かない場合があります(ただし、おそらく最後のものは興味のある場合ではありません)に)。
mmapされたファイルについて考えられる最善の方法は、実行可能な場合、対象の各ファイルを個別のデバイスに配置し、デバイスの統計情報を使用して使用情報を収集することです。これにはlvmパーティションを使用できます。新しいブロックデバイスを作成しないため、バインドマウントは機能しません。
ファイルを別のブロックデバイスに配置したら、/ sys / block / *または/ proc / diskstatsから統計情報を取得できます
これを実稼働サーバーに導入するのはあまりにも混乱を招くかもしれませんが、おそらくそれを利用することができます。
ファイルがマップされていない場合は、はい、ここで他のソリューションのいずれかを選択できます。
http://dag.wieers.com/home-made/dstat/を確認することをお勧めします。この優れたツールにより、多くの統計情報を確認できます。