WebSphere Message Broker on Windowsのヒープを解析
自分の仕事はほどほどに、今日は他のことに首を突っ込んでいた。
まず、タスクマネージャーからダンプファイルを作成します。
対象のプロセスは、DataFlowEngineって名前だったはず。
これまでWMBでやったことはないが、家で研究用に使ってるWASD8.0/8.5で試したことはあるので自信はあった。
ダンプファイルは、システムのテンポラリフォルダに、DMP拡張子で作成されて、出力先を示したダイアログがでる。
パスをコピーしたのち、DMPファイルを違うところに切り取って移します。
単純にテンポラリで作業したくないだけです。
これをJRE付属のjextractを使ってzipにします。
MQSIがインストールされてるところに、JREが付いてたはずで、それを使わないといけません。
jextractは、バージョン違うと激おこぷんぷん丸。
jextractが済むと、zipファイルができて、いつもならMemory Analyzerを使うんだが、そんなオシャレなものがそこの端末にないんで、JDK付属のjdmpviewを使うことにした。
jdmpviewに-zipオプション付けて読み込む。
見たいヒープの場所は、クラス名で特定可能だったので、x/jコマンドを使った。
引数にクラス名を渡すと、そのクラスの全オブジェクトのアドレスを知ることができる。ちなみにパッケージ名はスラッシュ区切り。
オブジェクトごとに、持ってる文字列とか違うんで、見たいオブジェクトはそういう情報を元に判断。
グイグイとオブジェクトを追うには、
ひたすら参照アドレスをx/jで追えばいい。x/jの引数にアドレスを渡して打てばいいだけ、コピーして貼り付けて叩くの繰り返し。
ダンプは2回とった。
テストを動かす前と後で、アドレスが変わってるオブジェクトがいる。
そんなとこ触ったつもりはないんだが、確かに変わってる。
それが分かったくらいでも一つの切り分けになる。
ダンプファイルの作成ではGC走らないため、古いアドレス位置をx/jするとまだ生き残ってて見れる状態だった。
やはりテスト動かすと誰かが書き換えてるのがこれで確定したわけだ。
そのあと紆余曲折して、メッセージフローをデバッグしたり。
ダンプ見る前にも張ってたブレークポイントだが、なんかその時は止まらなかったようだ。止まったときはやっぱり呼ばれてたかという反応。
そんなJMSメッセージを投げたつもりはなかったんだが、デバッグしてる中で、ブローカーツールキットのexeから投げられたことが、JMSメッセージの中身から分かったので、絶対にテストケースでメッセージを投げてると断定できて、最終的に投げてる箇所を発見にいたる。
ユーザー名とか、exeの名前とか、メッセージに乗ってるので、確認するのはわりと大事。
今回書いたWindows環境のWMBのヒープを見る方法は、知ってる人が少ないんで、使う機会も少ないだろう。
はあ、腹減った。今日はまだ何も食べてない。腹と背中がくっついてる。
