 Print-friendly Version
DTrace の開発チームによる Q&A です。 この記事は、 XPert Transcript: DTrace - Dynamic Tracing Framework (Last Updated November 10, 2004)を翻訳したものです。
Q: DTrace を使って何ができるのですか A: DTrace の使用例をいくつか示します。
Q: DTrace の詳しい情報が分かるドキュメントはどこにあるのですか A: BigAdmin DTrace ページに初期ドキュメントがあります。 Q: アプリケーションを再コンパイルしないと DTrace を使えないのですか A: いいえ。 アプリケーションを起動し直す必要さえありません。 Q: パフォーマンスに何らかの影響はありますか A: DTrace を無効にすれば、パフォーマンスにまったく影響はありません。 DTrace フレームワークでは、30,000 以上のプローブを自由に有効にできます。 そのうちのいくつかを有効にするだけであれば、パフォーマンスへの影響はあまりありません。 すべてのプローブを有効にすると、パフォーマンスに体感できる影響が表れますが、その場合もマシンは正常に動作します。 Q: DTrace は x86 プラットフォームで動作しますか A: もちろんです。 DTrace は SPARC と x86 のどちらのプラットフォームでも完全に機能します。 実際、ほとんどの開発 (そして公開デモの約 99 %) は、Solaris OS, x86 Platform Edition を搭載したラップトップコンピュータで行われています。 Q: DTrace についての Sun Blueprints Book の出版予定、または 「DTrace のベストプラクティス」のような Online BluePrints 公開予定はありますか A: 今後もさまざまな手段を使って、DTrace についての情報の提供を続けていく予定です。 現在、Solaris Dynamic Tracing Guide (http://docs.sun.com) に、BluePrints 形式の事例を豊富に掲載しています。 これらの情報は、docs.sun.com や BigAdmin の Web ページから入手できます。 BluePrints について特に役立ったと思われること、あるいは現在のドキュメントに欠けていると思われることがあれば、電子メールか、または DTrace BigAdmin フォーラムでお知らせください。 どのようなスタイルの情報が必要か、より短く、より簡潔なクイックスタートガイドが良いのか、それともより詳しいケーススタディが良いのかなど、ご希望をお寄せください。 皆様からのフィードバックを、BluePrints などで提供する今後のドキュメントのスタイルを決定するうえでの参考にさせていただきます。 Q: DTrace と truss には、どのような違いがあるのですか A: DTrace と truss(1) の主な違いは 2 つあります。 1 つは、DTrace では truss に比べて影響が非常に少ない方法で情報を収集できること、もう 1 つは、DTrace ではプロセスだけでなく、システムの多方面にわたってシステム全体の調査ができることです。 ここからは、この 2 つの違いについて、さらに詳しく説明します。 truss(1) は、1 つ以上のプロセスのシステムコールをトレースするユーティリティで、proc(4) ファイルシステムが情報の収集手段として使われます。 /proc は伝統的なデバッグユーティリティ用として考案されたものなので、その根底には、プロセスを停止してから、そのプロセスの各種状態ビットの読み取りや書き込みを行い、その後で停止していたプロセスを再開するという考え方があります。 そのため、truss では、実行されたシステムコールから制御が返されるたびにプロセスが停止され、結果が報告された後でプロセスが再開されます。 DTrace のトレースフレームワークでは、データの収集方法に若干の違いがあります。 すなわち、DTrace ではシステムのさまざまなコードパスを動的に計測し、データをバッファに記録できます。 そして、そのデータはユーザーランドコンシューマに定期的にコピーされ、フォーマット化されます。 したがって、コードの流れによって処理が一時的に中断され、DTrace に制御が移ったとしても、概念上は /proc のように、わざわざスレッドやプロセスを「停止」する必要はありません (もちろん、stop() アクションを使用すれば、スレッドやプロセスの停止は可能)。 このことから、DTrace のプローブの影響は、truss(1) のような /proc に基づくツールに比べて、一般にはるかに軽微です。 2 番目の主な違いとして、DTrace ではプロセスモデルだけでなく、基本的にシステムのあらゆる動作を観測できます。 さらに、DTrace は「D」というトレース言語を使ってプログラミングできるので、コマンド行スイッチで設定可能な処理に限らず、基本的にあらゆることを実行できます。 実際、Sun の『Solaris Dynamic Tracing Guide』の第 1 章を参照すると、読み取り/書き込み用の簡略化版の truss を、数行の D コードで実装できることが分かります。 したがって、DTrace では proc プロバイダや syscall プロバイダを使って、/proc と同様の情報を参照できますが、これらの処理を自由にプログラミングすることもできます。 また、その情報を I/O 情報、CPU のスケジューリング、vm の統計情報、ユーザー関数の呼び出しといった、他のプロバイダからの情報と組み合わせることも可能です。 さらに、DTrace では、システム全体、プロセスごと、スレッドごと、ファイルごとなど、作成した任意の数の「視点」から情報を参照することもできます。 このように、DTrace では、プログラミングが可能な汎用の機能を使って、基本的にシステムについてのあらゆる種類の情報を収集できます。 それと同時に、特定のプロセスのシステムコールの動作について、特定の情報を知りたい場合、そして、その情報を truss に搭載されている機能で十分に収集できる場合、従来と同様に truss(1) も問題解決のための重要なツールとして使用できます。 Q: 開発したアプリケーションで何が起きているのか分かりません。 (vmstat、iostat、mpstat で調べた限り) メモリインテンシブにも、I/O インテンシブにも、CPU インテンシブにもなっていないようです。 このようなときに、Dtrace でボトルネックを解明するにはどうすればよいのですか。 sched、io、pid プロバイダについての章をざっと読んでみましたが、手がかりが得られません。 何かアドバイスをしていただけませんか。 A: なぜ、アプリケーションの実行の制約になっている物理リソースが「ない」のか。 それが問題です。 1 つの物理リソースだけに制約されているのが、(パフォーマンスの観点から見た) 理想的なアプリケーションです。 このようなアプリケーションであれば、その物理リソースのパフォーマンスを改善するだけで、アプリケーションのパフォーマンスを改善できます。 ほとんどのアプリケーションでは、CPU バウンドが望ましい状態でしょう。 アプリケーションが CPU バウンドでは「ない」のであれば、「なぜそうなのか」を考えるべきです。 この疑問についての答えを得るには、sched プロバイダを使って、CPU がフル活用されていない理由を明らかにするだけで済みます。 sched プロバイダの章を熟読されることをお勧めしますが、まずは次の調査から始めるのがよいでしょう。
これで、何らかの手がかりが得られるはずです。もちろん、その手がかりも DTrace で詳しく調べることができます。 追伸: DTrace の機能は本当に素晴らしいと思います。ただ、その使いこなし方がよく分からないのが難点です。 ご指摘ありがとうございます。 DTrace の「ベストプラクティス」を中心に、ドキュメントの改善に取り組んでいきます。 Q: DTrace は、ユーザーアプリケーションのメモリ破壊やメモリリークの検出に使用できますか。 もし使用できるのであれば、Purify のライセンスを破棄しても構わないのですか。 A: これらの作業には、Purify よりも libumem(3LIB) の方が適しています。 libumem は、Solaris 10 の新しいメモリアロケータです。 詳細については、umem_debug(3MALLOC) のマニュアルページや、この件についての Adam のブログ (http://blogs.sun.com/roller/page/ahl/?anchor=solaris_10_top_11_20) を参照してください。 Purify とは違って、libumem ではパフォーマンスにほとんど影響を与えずにチェック機能を組み込むことができます。 これらのチェック機能は本稼動システムでも有効にしたままにしておくことができます。 そして、gcore と ::findleaks を使うと、アプリケーションを実行しながらメモリリークを検出できます。 ここでも DTrace が役立ちます。 libumem を使うと、メモリリークやメモリ破壊の原因を推測できる場合があります。 そのようなときに、DTrace を使うと、その推測が当たっているかどうかを素早く確認できます。 皮肉なことに、筆者は最近まさにこの方法で、dtrace(1M) コマンド自身のメモリ破壊をデバッグしました。 まず、libumem とそのデバッグ機能を使って問題を調査したところ、すでに解放されている構造体がアクセスされていることが分かりました。 そこで、解放が発生している場所のスタックトレースを取得したところ、その構造体を包含している構造体自身が正しくクリーンアップされていない可能性があるという結論に達しました。 DTrace を使うことで、この推測を調査し、包含元の構造体が実際に誤って再利用されていることを確認できました。 libumem と DTrace のおかげで、この段落を書くのとほとんど変わらない時間で、問題を解決できました。 自分が開発したツールで、自分が犯したバグを取る。 これほど開発者冥利に尽きることはありません (苦笑)。 Q: 私はある銀行でセキュリティアナリストとして働いています。 DTrace はセキュリティにどのように役立ちますか。 すべてのマシンで BSM を実行しているのですが、DTrace と BSM の両方を実行すると、パフォーマンスに影響しますか。 A: DTrace 自身はセキュリティツールではありませんので、BSM の機能と干渉することはありません。 パフォーマンスへの大きな影響を心配することなく、同じマシンで両方のツールを実行できます。 DTrace で使われるのは動的計測機能だけなので、DTrace が使われていないシステムは、DTrace がインストールされていないシステムと同じです。 したがって、DTrace を無効にすれば、パフォーマンスへの影響は実質的にゼロになります。 また、DTrace を使用した場合、ユーザーが要求した計測だけが選択的に有効になり、処理も動的に実行されるので、要求した処理に見合ったパフォーマンスコストしかかかりません。 セキュリティを担当されている方は、『Solaris Dynamic Tracing Guide』のセキュリティについての章を参照し、DTrace 自身のセキュリティ機能を確認してください (この資料は docs.sun.com や BigAdmin から入手可能)。 DTrace へのアクセスは制限され、user_attr ファシリティにより、最低権限ビットを使って特定のユーザーによるアクセスを制限できます。 また、DTrace プログラムのエラーによって、システムがクラッシュすることもありません。
質問: [ 1〜10 ] | [ 11〜18 ]
|
 
BigAdmin SubscriptionsBigAdmin Areas
BigAdmin Sun Center
BigAdmin Topics | |||||
 | |
