最近のインタビューにおいて、Philippe Hanrigou氏はRubyのモニタリングとトラブルシュートのトピックを深く掘り下げている(source)。なぜRubyのプロセスが失敗するのか、またメモリリー クもしくはパフォーマンス問題が発生するのか理解することは、アプリケーションを動作させ続けるためにはとても重要な事なのである。これを迅速に理解することは更に重要で、特にもし本番機が問題を発生しこれがビジネスの障害になっているのならなおさらである。
gdbかもしくはstraceのような基本的なUnixツールの次にDTrace(サイト・英語)は可能性がある実用的なツールとして挙げられた。プログラムの追跡と低オーバーヘッドプロファイリングを可能にするツールである、DTraceはもともとSolarisのために開発された。それ以来他のシステム用にも開発されている。一番最近ではRubyインタプリタ用のDTraceサポートツールを含むMac OS X Leopardに対してそれが行われている(source)。
Philippe氏はDTraceが未だサポートされていないLinux用のソリューションを提案している。
Philippe氏はRubinius(source)における興味を示しその幕を閉じた。
gdbかもしくはstraceのような基本的なUnixツールの次にDTrace(サイト・英語)は可能性がある実用的なツールとして挙げられた。プログラムの追跡と低オーバーヘッドプロファイリングを可能にするツールである、DTraceはもともとSolarisのために開発された。それ以来他のシステム用にも開発されている。一番最近ではRubyインタプリタ用のDTraceサポートツールを含むMac OS X Leopardに対してそれが行われている(source)。
Philippe氏はDTraceが未だサポートされていないLinux用のソリューションを提案している。
一番コアなコミュニティのメンバーのほとんどにとって、SystemTapを前進させる事に時間と労力を費やすのは価値あることなのかもしれない。あいにくたくさんのRubyアプリケーションがLinuxの上でデプロイされている一方、DTraceはこのプラットフォームにおいて可用ではないのである。ライセンスと未解決の問題があるため、DTraceが近い将来Linuxにポートされる可能性はほとんどないのである。LinusにおけるDTraceに一番近い代替案は同じ目的を持っているがまだ完成度の低いSystemTapなのである。特にSystemTapはユーザスペースプログラムにおいて、追跡用のサポートを提供していないようだ。JRuby上でRubyを動作するとJavaプラットフォーム用に可用なプロファイリングとモニタリングツールのホストへのアクセスがデベロッパたちに与えられる。Ola Bini氏は一昔前に”あなたのルビーはこれができますか(source)”というブログ上でこれを利点として言及していて、JRubyアプリケーションの中を探るためにJCosole(JDKと一緒に発売される）を使用している。JCosole(source)は動作中のJVM、またJMXを使用してガーベージレクション情報、スレッド 情報、またMBeansを通して表示された全ての情報に添付することができる。Phillip氏はまたメモリリークに対応するもう一つのツールに関して言及している。
最後にメモリリークとなると通常のJavaツールがレスキューに来ます。実用的なテクニックはjmapでヒープダンプを取得し、それをjhatかもしくは標 準的なヒープダンプアナライザを使用してインスペクトすることです。そこでSAP Memory Analyzerを試してみて欲しいのです。Ola氏はそれで素晴らしい体験をしています。最近InfoQはSAPかもしくはIBMのフリーメモリアナライザに関するディスカッションを行っている(参考記事)。
Philippe氏はRubinius(source)における興味を示しその幕を閉じた。
最後に、もしRubyデベロッパがそれを拡張するために簡単にRubyインタプリタにアクセスできるのならば、Ruby用のトラブルシューティングツールを 構築することは遥かに簡単になるでしょう。これが、なぜ私がRubiniusのようなプロジェクトの成功がプラットフォームを長期的に全く新しいレベルに 持っていくためのベストな方法であると考えている理由なのです。Rubiniusに投資するコミュニティの時間と労力は報われることでしょう。原文はこちらです：http://www.infoq.com/news/2007/12/monitoring-ruby