koie blog : DtraceDay 2010.03

DTraceの話が聞けるというとで用賀のSun Microsystemsへいってきた(初めて)。

= 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
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)
まとめ
- まずどのプロバイダをつかったらいいかがわからない。
- いろんな視点から調べて問題個所をしぼりこむ。
- いきなりあれこれしないのが吉
デモは省略...
(疑問点)
- 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が増えているのでチェックしよう。