カーネル挙動を追尾する「DTrace」の実力OS選択の新常識(8/8 ページ)

» 2005年04月22日 13時53分 公開
[大澤文孝,ITmedia]
前のページへ 1|2|3|4|5|6|7|8       

syscall::write:entry
/self->filedes == arg0/
{
        printf("writedata : %S", stringof(copyin(arg1, arg2)));
}

 writeシステムコールには第1引数(arg0)に書き込み先のファイルディスクリプタが渡される。そして、第2引数(arg1)には書き込みデータへのポインタ、第3引数(arg2)には書き込むバイト数が渡される。

 self->filedes変数には、先のopenシステムコールのreturnプローブでファイルディスクリプタを保存しているから、「self->filedes == arg0」は、「対象のファイルへのwriteシステムコールが発生したら」という意味になる。ここでは、copyinサブルーチンを使ってバイト列を文字列に変換したものを、printf関数を使って出力しているのだ。

 DTraceでは、標準で保存可能な文字長を256バイトまでとしている(Solaris Dynamic Tracing Guideの「Chapter 6 Strings」を参照)。そのため、256バイト以上のデータは切り捨てられるのだ。

統計情報は容易に得られるがデバッグ目的は苦労する

 ここまで説明してきたように、DTraceを使うと、統計情報はもとより、データの中身も見られる。使い方によっては、パフォーマンスのボトルネックになっている部分を調べるだけでなく、デバッグの強い味方にもなるだろう。

 Dスクリプトの構造は、ここまで見てきたように比較的難しくはない部類だ。むしろ理解しなければならないのは、Dスクリプトの書き方ではなく、プローブからどのような情報が得るのかを幅広く知ることだ。Solaris Dynamic Tracing Guideには、さまざまなプローブの情報が記されているので、一読しておきたい。

 統計情報を得るという目的であれば、Solaris Dynamic Tracing Guideを読んで、欲しい情報を提供してくれるプローブを限定し、それを集計するスクリプトを作るだけで役立つ情報を得られるだろう。

 しかしデータの中身まで見たいということになると、少し話が複雑になる。なぜならば、「どのようなシステムコールがどのような時に、どのような引数を伴って呼び出されるのか」を知る必要があるからだ。

 任意のコマンドがどのようなシステムコールを呼び出すのかは、trussコマンドを使うことで目安を付けることができる。例えば、「echo "abcdef"」と実行したときにどのようなシステムコールが呼び出されるのかを知りたければ、次のように指定すればよい。


# truss echo "abcdef"
execve("/usr/bin/echo", 0x08047E14, 0x08047E20)  argc = 2
resolvepath("/usr/bin/echo", "/usr/bin/echo", 1023) = 13
resolvepath("/usr/lib/ld.so.1", "/lib/ld.so.1", 1023) = 12
xstat(2, "/usr/bin/echo", 0x08047C08)           = 0
open("/var/ld/ld.config", O_RDONLY)             Err#2 ENOENT
sysconfig(_CONFIG_PAGESIZE)                     = 4096

 しかし、このそれぞれの関数に引き渡されるデータを読み取るには、どのような構造体もしくはポインタなのかといったC言語の知識が必須だ。

 またSolaris Dynamic Tracing Guideでは、すべてのプローブの情報が詳細に記されているわけではない、という点も少し問題になる。

 実はこの特集で当初は、「ネットワークから届いたデータの監視」も例として採り上げようと予定していた。例えば、ポート80への受信データを監視して表示できれば、Webクライアントからどのような要求が送られてくるのかを見ることができ、Webアプリケーションのデバッグに役立ちそうだと思ったからだ。

 筆者が調査をした結果、fbtプロバイダ内のプローブを使うと、送受信されるTCPのパケットを見られるということが分かった。しかし、fbtプロバイダ内に関する情報は少なく、また、TCPのパケット単位での監視となる。また、それを結合する処理も必要となるため、今回は見送った(読者が勘違いしないように付け加えておくと、プロセスがネットワークを通じて送受信するデータ量は、mibプロバイダから容易に取得ができる。ここで述べているのは、データの中身を見るのが容易ではないという意味だ)。

 現状では、DTraceに関する資料は少なく、試行錯誤しながらスクリプトを作っていくという手探りの状態にある。そのため、カーネルやシステムコールに詳しくない人にとっては、自分が収集したいデータを得るためのスクリプトを作るのは難しいかもしれない。しかし今後、スクリプト事例が増えたり、DTraceを使ったパフォーマンス計測のノウハウが蓄積されてくると、比較的カーネルやシステムコールに詳しくない人でもDTrace活用ができるようになるだろう。サンは、Open Solarisでこのような広がりも期待しているわけだ。

前のページへ 1|2|3|4|5|6|7|8       

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ