プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

DTrace研修2日目 このエントリーをはてなブックマークに追加

めんどいので簡潔に


  • DTraceではself->variable構文をつかうと、per CPU variableを使うので var[hash] よりも速い事が保証されている。連想配列あるからいいじゃんとか言ってるSystemTapは空気読めてない子
  • DTraceではAggregation関数で集計すると自前で var += hoge とかやって集計するよりも速い事が保証されている。これは言語の使用目的を考えると必須だよな。とか思った
  • DTraceは収集時にAggregate関数の種類を選ぶが、SystemTapは表示時に選ぶ。DTrace方式のほうが無駄な収集が発生しないので賢い
  • Speculative Tracingってなんじゃらほい?と思ったら単に主バッファとは別のバッファがつかえるよ。
    というだけだった。でも構文は汚いと思う

    • バッファアロケートが関数なので、実行時にしか何個バッファが生成されるか分からない。
      どう考えても普通はせいぜい1つしか作らないので、柔軟性より速度を追求した方がよい
    • 書き出し先バッファ切り替えが関数なので汚い。どうせ1関数内で複数のバッファに書くことは
      言語使用上禁止されているのだから関数の修飾子とかにしたほうがよかった気がする

  • early boot tracingはかなりがんばっている。SCSI やFilesystemより先にロードされてるんだけど
     どうやってるんだ?
  • SolarisではELFを独自に拡張してDTrace用のSymbol Tableを別途持っている。かつこれはstripの
    対象外なので、stripされたバイナリからでもシンボルが引ける。これはユーザアプリのトレースで
    重要な性質。static関数もちゃんとテーブルに名前が残ってるし。SystemTapは行番号トレースと
    ローカル変数の参照をサポートしたぶんだけ、必要な情報量が爆発的に増えており、事実上
    DWARFを使うしか手がない。
    stripされたバイナリをトレースできるようにするのは、仕様変更がいるなぁ
      http://blogs.sun.com/ali/entry/what_is_sunw_ldynsym
      http://blogs.sun.com/ali/entry/inside_elf_symbol_tables
  • バッファポリシーとして

    • switch
    • fill
    • ring

    の3つをサポート。switchがデフォルト。
     残り2つはearly boot tracingと組み合わせて使う。
     fillがバッファがいっぱいになったらこれ以上記録しない。というバッファ。ブート時のログを
    とりたいときはバッファがいっぱいになったら自動的に止まって欲しいからね。
    ringは逆にバッファがいっぱいになったらバッファ先頭にもどって上書きしていく。
    んで、なんかおかしくなったときに、最後のほうのログを吸い出す。
    いわゆるフライトレコーダー目的
  • ユーザ空間のトレースはある関数の全instructionにprobeをしかける。とか出来るので、
    エラーが発生した箇所を細かく絞り込むことが(根気が許せば)可能
  • profile provideはトレース間隔に109とか4999とか変な数値がデフォルトになっているが、
     キリのいい数字にすると毎回クロック割り込みとぶつかっておかしな集計結果になるから。
    賢い


とりあえず、SystemTapも.SUNW_ldynsymをサポートして「でもstripされていたら行番号トレースはできないからね」という仕様にしたほうがLKMLでdisられなくなっていいんでは?とか思った

関連記事


linux | 【2008-10-21(Tue) 21:19:03】 | Trackback:(0) | Comments:(8)
コメント

back port 期待してます :D
2008-10-22 水 02:51:45 | URL | hogerattan #SFo5/nok [ 編集]

hogerattan様>
ははは、鋭意努力いたしまする。。。(^^;
2008-10-22 水 21:27:31 | URL | kosaki #- [ 編集]
このコメントは管理人のみ閲覧できます
2008-10-23 木 00:11:28 | | # [ 編集]

self->variableで使える変数って何に使うんでしょうか?CPU毎の統計でしょうか?
(selfの主体は「このCPU」という意味?)

Aggregator(stapだとstatistics)の実装をスクリプト変換時に自動選択するのは、難しいことではないので、要求だせば作ってくれるかも。
2008-10-23 木 12:19:15 | URL | mhiramat #- [ 編集]

selfの主体はスレッドですね(つまり per CPU variableと書いたのは間違っています。すいません)
ハッシュでTIDをキーにするケースって意外と多いんですよ。。。
引数がxxだったらフラグをONにしておいて、フラグがONだったら戻り値を記録みたいなケース。
んで、頻出だから専用の速い実装を用意してある。と

ん、まあSystemTapはコンパイラがリキ入っている系なので、コンパイラでがむばって解析すればいいのかもしれんけど。
2008-10-23 木 13:07:11 | URL | kosaki #- [ 編集]

解説ありがとうございます。selfの主体がスレッドなら確かに納得できます。大体のトランザクションはスレッドを追っかければいいので。
高速に実装するとすれば、プロセス構造体の一部あるいはスタックの一部にローカルデータへのポインタを潜ませるのがいいかな(安全性はともかくとして(ぉぃ))。もしかするとutraceの拡張で何とかなるかもしれないなあと思ったり。
2008-10-25 土 09:25:22 | URL | mhiramat #- [ 編集]

どうやらsystemtapでも、Aggregatorの生成時にスクリプトをパースして、ヒストグラム系の処理が入っていなければそれは飛ばす(statisticsの実装が変わっている)みたいですね。
maxとかminとかcountとかは無条件で処理されるようですが。
2008-10-26 日 16:06:44 | URL | mhiramat #- [ 編集]

おおー。なるほど。
んじゃ、SystemTapでaggregatorは遅いから使うなってのは過去のTipsになっているということかな。
今度速度計ってみます。
2008-10-27 月 00:35:47 | URL | kosaki #- [ 編集]
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。