DTraceの話が聞けるというとで用賀のSun Microsystemsへいってきた(初めて)。
- http://wikis.sun.com/display/JpOpenSolaris/DTrace+Day+2010.03
- http://atnd.org/events/3271
- #dtraceday
= DTrace概要
- 7年まえからあまり変化はない。
- 致命的: core,crashdump=フライトレコーダ
- 一時的: debuggerは実環境ではつかいにくい
- 稼働中でも動的計測したい!
- trace offならオーバーヘッドなし。
- 観測点を絞ることでオーバーヘッドを抑制。全部onにすると動かなくなるほど重い。
- D script (D言語とはいわない)
- 実施には特権が必要
- scriptは中間言語になってカーネルで検証される
- javaとちがってD scriptではpointerがつかえる; null pointer deref/zero divはチェックされる
- 破壊的アクションはdefault off
- break pointのようなものも含む
- 利点
- 多角的に検証できる
- リソースの見積り精度があがる
- consumers (1M)
- dtrace
- intrstat
- plockstat
- lockstat
- probe
- privider:module:function:name
- provider
- dtrace
- initialize, finalize, error handling
- profile
- 単位時間ごとに状態の標本収集
- syscall
- sysinfo
- カーネル統計情報の取得
- vminfo
- proc
- sched
- io
- dtrace
- consumer
- DTrace機構とやりとりするプロセス
- 複数コンシューマの同時実行ok
- D Script
- C like
- 組み込み関数/変数が便利
- eg timestamp
- thread local storage
- 節固有変数
- kernel C データヘの完全なアクセス
- buffer
- trace actionがデータを記録; trace(expr) //printfのようなもの
- 集積関数
- 集計
- awk/perlで後処理しなくてすむ
- @name[keys]=func(args)
- syntax
プローブ ←provider:{module}opt:{function}opt:Name '*'もつかえる/述語/
{
アクション文 ←ここでifがつかえないので述語が必要になっている
}
- - サンプルツール
- - /usr/demo/dtrace (solaris10)
- /opt/DTT (opensolaris)
- - /usr/demo/dtrace (solaris10)
- まとめ
- まずどのプロバイダをつかったらいいかがわからない。
- いろんな視点から調べて問題個所をしぼりこむ。
- いきなりあれこれしないのが吉
- デモは省略...
- (疑問点)
- ILP32,LPl64
= ユーザープログラムでのDTrace 導入編
- 公式ドキュメントにすべて書いてある (必携)
- ちょっと堅苦しい...
- gihyoのは全8回予定
- probe-description [,..] { action-statements }
- probe-desc ::= probeprov:probemod:probefunc:probename
- probeprov ::= 機能の種類
- probemod ::= バイナリファイルを指定 省略すると全部になるので注意
- probefunc ::= 関数限定
- probename ::= entry,returnとか
- デバッガでattachしているとdtrace -pはできない
- 対策: dtrace引数でpidを指定することにしてscript内で pid$2 とかして参照する
- stringof(copyin(addr))
- 固定長で\0ないやつもある。
- copyinはデフォルト長でcopyしてくる。オプションをつければ変えれる。1MBとかも。
- clause local variableはCの局所変数相当だがmultithreadのときは要注意。
- pidプロバイダのreturnプローブは arg0 が戻りアドレス arg1 は戻り値だがvoidだと不定値に。
- ustack()アクションでスタックトレースがとれる。
- probeのためのTRAPはdtraceコマンドがやる。カーネルではない。
- forkするとpidがかわってしまうのでトレースできなくなる。
- execするとTRAPが上書きされてしまうのでダメ。
- inetdから起動されるデーモンだと仕掛が必要。
- あえて予想不能は挙動にならないようなガードだと考えてみる。
= ユーザープログラムでのDTrace 応用編
- プログラムを改変して関数境界以外で情報をとる
- dtrace -GでプローブをNOPでおきかえてcheckpoint.oに位置情報を保存する。
- 副作用があってもそこは評価されて捨てられるだけ。
- pfexec:sudoみたいなものか
- 可変長のメモリを採取するには
- inline int xxx = nnn; ←マクロ相当
- なんでこんなことになっているのか
- self->bufとallocaの寿命 checkはなし 範囲checkだけ
- loopがないのは 有限時間で止まるのを保証するのはたいへんなため
- 実はバイトコードを書けばループはつくれるかも
- /../と?:しか条件分岐がかけない。
- isainfo -v
- intかlongとかは注意するしかない。
- *_ENABLED()は関数単位でon/offできる
- sparcはlittle overheadだけどx86はそれほどでもない。
- sparc 2clockくらい
- amd64 2clockぐらい?
- 32bitはためしていない
- kernelのprobeならオーバーヘッドはよりすくなくなる。
- PROV_PROBE(*x.p)とするよりは、PROV_PROBE(x)としておいてスクリプトで*pをcopyinしたほうがいい。
- 32/64は指定しないとだめ。
= デモ
- chime: dtraceとおなじ引数でGUI
- 度数分布とか
- 時間経過とかで
- sshkeysnoop.d
= 合同セッション
- solaris bsd mac
- 開発 運用
- driver
- FBTベース (function boundary trace)
- 時間制約があるので..
- kernel moduleはロードするときにNOPにおきかえている
- system tap
- TRAPなしでユーザ空間だけでなんとかしているらしい
- 定期的にバッファをカーネルに渡している?
- pidプロバイダだとlibcでプローブをいれると全プロセスで共有されてしまうのでpidで外せるけど激遅に。
- デバッガもトレースをうめこむとききにprivate mappingするので相性がわるい
- /opt/DTT
- DTrace Toolkit
- 他でも動くが、probepointの名前が違うので動かないかも。
- ワンライナーだけでなく、こういうのは便利。
- 勉強にもなる
- shellscriptの方が大きかったりして
- minfbypi マイナーフォールト調査
- iotop
- 不安定なインタフェイスをつかうと、いきなり構造体がかわって動かなくなったり..
- ユーザランド: 構造体も#includeすればいけるが、だめなケースもある。
- コンパイラオプションも合わせないといけない。
- parserは自前でもっている。
- セクション .SUNW_dof があるとプロバイダがうまっていることがわかる。
- pythonももってる、firefoxとかも、
- /opt/DTT/perl/Readme: ビルド方法が
- /opt/DTT/php/Readme でもl php.ini にオプション指定が必要。どの関数が重いかもすぐわかる。
- java hotsport provider
- ときどきbuiltinが増えているのでチェックしよう。
- 頂き物
- Tシャツじょうぶだそう。日本でももうすぐSUNのマークが使えなくなるらしいのでゲット。
- 途中で捨てたりしないでください。次の日にホームレスの人がみんな同じのを着てたりするので(笑)