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

Solaris 10の強化機能としてクローズアップされることが多い「DTrace」。さまざまなサービスが並列稼働する基幹サーバでは、カーネル挙動によってボトルネックを判断することも多い。DTraceは、解決するための打開策となるのか？　実例サンプルで検証していく。

[大澤文孝，ITmedia]

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

リスト2　ファイルの読み込みに要した時間計測（filereadtime.d

　リスト2では、readシステムコールのentryプローブとreturnプローブを処理している。

　entryプローブでは、timestamp変数を使って現在のタイムスタンプを取得するビルドイン変数であり、ナノ秒単位での値を保持している。entryプローブの処理では、次のように「self->time」という書式を指定している点に注目しよう。

self->time = timestamp;

　「self->」という書式は、「スレッドローカルな変数」を示すものだ。プローブは異なるスレッドで同時に呼び出される可能性があるが、「self->変数名」という書式を使うと（ここでは変数名としてtimeという名前を用いたが、これは任意名でよい）、スレッドごとに別々の変数が用意されるため、値が混じらなくなる。

　なお、Dスクリプトでは、「self->変数名」と似た書式として「this->変数名」という書式も用意されている。「this->変数名」はブロック内でのみ有効な一時的な変数（C言語で言うところの自動変数。Perlで言えば、My）だ。

　さて、returnプローブでは、次のように現在のタイムスタンプ値から、先にentryプローブで保存しておいたタイムスタンプ値を引いたものの総和を採っている。

@time[execname] = sum(timestamp - self->time);

　これにより、entryからreturnまでの所要時間――readシステムコールが呼び出し終わるまで――の合計を求められるという仕組みだ。

　実際に実行すると、次のように、コマンドごとにファイルの読み込みに要した時間総計がナノ秒単位で表示される（表示される内容は環境によって異なる）。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***