systemtapの情報源

Linux版DTraceともいえるsystemtapのチュートリアルは2007年に作成された日付がありますが、一通り読んでみて入門としてはとても良くできているという印象を受けました。

次に関連する情報はないかなぁとGoogleで調べていたのですが、 そこでひっかかったのが、@ITで連載されていた”Linuxトラブルシューティング”シリーズの記事、「最終回　SystemTapで真犯人を捕まえろ！」でした。

systemtapに限らず全体的に内容が高度に見えて、でも切り口が日常的にどこかで発生していそうな事象を扱っている点が秀逸だと思います。 時間みつけて@ITの記事は抑えておいた方がいいかなぁ。

メモリ周りの思い出

昔の仕事でJavaを使っているときは、そのJavaの世界だけで起こる奇妙な現象には悩まされました。 JVM自体に問題があればsystemtapなんかでも分かるんでしょうけれど、Javaの世界で完結している場合にはGCのログファイルと解析ツールが必須になります。

最近ニコニコ動画でWPFを使ってGCの様子を可視化している動画をみましたが、”Javaの場合”、

• まだ隙間があるのにいきなりコンパクション走るのか
• コンパクションはもっと重い処理として表現して欲しい

などと思ったのは私だけでしょうか。

Javaの場合はトータルの空きメモリは10MBあっても、1MB分の配列を宣言するとOutOfMemoryExceptionが発生する場合という事もあり得ます。環境によっては100MBの空き領域でも厳しいかも。 JVMが使うメモリ内部の連続空き領域を考慮しないと、サーバーサイドのJavaプログラミングはできません。

Javaは原理的にはC++のようなdelete()を忘れるタイプのメモリリークは発生しませんが、それでもオブジェクトへの参照が残っていればGCの対象にはなりません。 そもそもコード中のオブジェクト参照を完全にコントロールできれば、C++でもdelete()を忘れるという事は起らないでしょう。

そんなわけでオブジェクトの管理ができていない事で全体のメモリ使用率が上がって、Compaction Phaseで動かせないオブジェクトが残る事とあわさってOutofMemoryExceptionが起ります。 世代別GCも採用が進んで問題は起りにくくなっていますが、Compactionは完璧ではないのにGCに頼ってできる事をしない開発者が増えないか心配です。

GCは開発者をサポートしますが、怠慢をフォローすることはできないでしょう。

ディスクの使用率がなぜか下がらないとか

ほかによくあったのはディスク使用率の警告がでて、サイズの大きなログファイルを削除したのに警告が収まらないというものでした。

ファイルを削除しても、それ以前にopen()されたファイルディスクリプタをclose()しなければいけないのに、ログを吐き続けているプログラムが一旦起動したら停止するまでclose()しない仕様だったりすると最悪です。 Javaなんかだと裏側のライブラリがそういう設計だったりして、必ずしも開発者の単純な落ち度ということでもないのですが、いろいろみていると全体の環境を把握して維持する事の難しさを実感します。

より深刻な問題なのはそういう説明をしても理解できないアプリケーション開発者でしょうか。 プログラミングでJavaだけを教えるのも悪い事ではいのですが、せめてJVMの設計と実装についての講義も必修にして欲しいです。

あれ、systemtapのドキュメントを読んでいたはずなのにJavaの話しになってる…。