RubyKaigi 2015レポート

小崎資広さん「人に依存しないデバッグのために,道具の使い方を知ってほしい」〜RubyKaigi 2015基調講演 2日目

この記事を読むのに必要な時間:およそ 2 分

perfコマンド

2つ目のツールとして挙げたperfは,マシンのパフォーマンスについて様々な情報を取得できるコマンドです。いくつかのサブコマンドが実装されています。

まず紹介したのはperf topです。perf topは,プロセスの状況を見るtopコマンドのような見た目になっています。topコマンドはプロセスが主役となる見た目になっていますが,perf topコマンドは プロセスで使われているライブラリの関数が主役となる見た目になっています。そのため,システムがスローダウンしているときに実行し,その犯人探しをすることに使われるそうです。

次に,すべてのプロセスが呼んだシステムコールを全部ロギングしてくれるツールである,perf traceを紹介しました。このツールは,ネットワークやI/Oが原因で問題が発生したとわかるときに,その原因となっているプログラムを探すのに使われるそうです。

画像

最後に紹介したのはperf recordとperf reportです。pref recordは実行している間,ずっとperfの情報を取得してくれます。perf recordを終了後,perf reportで結果を確認できます。perf recordを実行すると関数名の一覧が表示され,画面を操作していくことでより詳細な情報を見ていくことができることを示しました。

SystemTap

3つ目のツールがSystemTapです。SystemTapは,デバッグのためのスクリプト言語です。SystemTapの言語仕様は貧弱で使いづらさはあるそうです。これはSystemTapのスクリプトがコンパイルされるとカーネル空間で動くツールとなるため,あまりシステムを負荷かけれてしまうスクリプトを組むのが難しいような言語設計にされていると言われている,と説明しました。

SystemTapはカーネルの関数をプローブすることで,その関数が実行されるときにフックしたりコールグラフを作成したりできるそうです。

画像

そして見つけたバグ

小崎さんは,SystemTapのデモを作成しているときにRubyのSystemTap対応にバグを2つ見つけたそうです。

1つ目は,disable-gemsを有効にしてRubyを実行した際,SystemTap機能が正しく動かないというバグです。こちらは,関数名のミスタイプが原因だったようです。SystemTap対応の元となったDtrace対応のころから入っていて,その後その箇所が何度か触られていたにもかかわらず残っているというのが今回初めてわかったとのことです。

画像

2つ目は,SystemTapではRubyの行番号を取得きるのですが,Cで書かれた箇所については取得できないというものです。この問題に対し,小崎さんはまつもとゆきひろさんが言っていた「RubyでできることはCでもできる」という言葉をだし対応したそうです。しかし,対応したもののRubyGemsの呼び出しが大量に表示されてしまうので,使うには不便という問題がわかったとのこと。この問題に対し,

  • kernel.#requireにオプションでファイル名と行番号を渡す
  • rubygemsがDTRACEHOOKを代わりに呼ぶ

という解決案を提案し,近日中にRuby Core Teamで議論したいと述べました。

まとめ

最後に,本日話した内容を次のようにまとめました。

  • Linux Portメンテナの役割について
  • Linuxのデバッグツール御三家の使い方紹介
  • 発表資料を作るとバグを見つけて作業が進まない
  • バグがたくさん直った

また,最後にRubyのDtrace,SystemTap対応には足りてない機能がまだまだあるので,フィードバックがほしいと話を締めくくりました。

著者プロフィール

三村益隆(みむらみつたか)

株式会社永和システムマネジメントで働くRubyプログラマ。Asakusa.rb所属。1983年生まれ。著書にパーフェクト Ruby(共著)がある。

Blog:http://d.hatena.ne.jp/takkan_m
Twitter:@takkanm