Performance Inspectorというプロファイリングツールを使ってみた
日本語資料がほとんど見当たらないので、なんか書き残しておこう。
Performance Inspectorの情報は、この２つを把握しておけばいいでしょう。英語だよ。
http://perfinsp.sourceforge.net/
http://www.alphaworks.ibm.com/tech/pi
Performance Inspectorはプロファイリングツールです。
僕はJavaで使いますが、Javaでない部分にも使えるようです。
ただし、僕はJava以外の部分は試してないのでここでは話しません。
（C/C++のコールフローもプロファイル出来るとかもね）
Performance Inspectorは、Windows,Linux,AIX,z/OSで使えます。
64bitにも対応してるみたいです。
z/OSで使えるって言っても、そもそも日本でz/OSってどれくらい使われてるんだ？
Performance Inspectorだけだと正直に言って解析になりません。
これはデータ収集はしてくれるけど、分かりやすくは見せてくれません。
それを補うのがVisual Performance Analyzerです。
http://www.alphaworks.ibm.com/tech/vpa
これはWindows,Linux,AIXで動くみたいです。
plugin版もありますが、rcpをお勧めします。
はっきり言ってメモリが足らなくなるから。
そろそろPerformance InspectorのWindowsへのインストールにおいてハマったことを書いておきましょうか。
手順通りにC:/ibmperf/を作る。
えーと、ddrというコマンドは、アンインストールみたいなものだろう。きっとdelete driverかな？
もしも、既にインストールされた状況で、別のパスにインストールし直すなら、
一度前のパスでddr打ってアンインストールしてからにしてください。
さてさて、zipを解凍して、tinstall.cmdを叩くと何か聞かれることでしょう。
Yesって答えてもたぶんエラーで終わる。
その際、symchk.exeが無いと言われているようであれば、きっと僕がハマった内容と同じです。
symchk.exeは、Debugging Tools for Windowsに入ってます。
このサイトに行って、探します。
http://www.microsoft.com/japan/whdc/DevTools/Debugging/default.mspx
Debugging Tools for Windows 32ビットを私は利用しました。
Symbolパッケージはいちおうダウンロードしましたが、結局使いませんでした。
symchkはシンボルのチェックという意味なんだろうが、シンボルってのが何を指してるのかは知らん。
なんでこんなもんが必要なんだろうか？
きっとプロセッサーの深いとこまで情報を追うんだろう。TPROFあたりかな。
Debugging Tools for Windowsは、Program Filesに展開されますが、PATHまでは通されてないようです。
なので、ちゃんとsymchk.exeが見つかるようにPATHを通し、念のため再起動。
この状況でようやくtinstall.cmdが動きます。
setrunenvを僕は打ちませんでしたが、手動でPATHを追加しました。
run.tprofやrun.itraceを打って、動くようなら正しい状態です。
あとでJPROFを使うでしょうから、PATHを通さないとJVMがライブラリを読めません。
また、JVM起動時にrtdriverで繋ぐでしょう。その際、どこのパスからでも繋げられた方がいいもんです。
Red Hatのv5あたりにも入れようとしたが、binutilsが足らないと怒られた。
んーむ、rpmでは2.17が入ってるんだが…。
binutils-develってのも必要らしい。
困った。僕はLinuxとかそんなに興味もないし、詳しくない。
この地雷は通らないことにした。
Performance Inspector ExamplesのJPROFのところを眺めてみる。
Java Pathlength Profiling
どこが特徴的なのかいまいち分からない。
java -agentlib:jprof=callflow[,start][,logpath=path] classfile
callflowはmetrics=ptt_insts+ptt_cyclesを意味している、メトリックスを指定する書き方にはエイリアスもあるってことだな。
まだメトリックの詳細な理解は進んでいない。
startは、データ収集をすぐに始めるかの指定です。
通常、rtdriverから「start」を送らないとデータ収集を始めませんし、それどころかrtdriverから繋ぎにいかないとjavaプロセスは途中で止まった状態でリッスンしてるはずです。アプケーションサーバーに仕掛ける際は、この指定はしない方が僕は良いと思いますが一長一短なところがあります。しない方が良いというのは、アプリケーションの性能を測る場合、サーバ起動時のコールフローを調査したいわけではないから。しかし、rtdriverから繋がないとサーバがちゃんと起動しないってのを面倒臭く思う人は、この指定をすることになるだろう。ただし、面倒臭さを軽減するために指定をしたならば、一回rtdriverからendを送り、そのデータをend(書き出し(flush)て終了)して、もう一度rtdriverからstartを送るってことになるんじゃないかな。(無駄なファイルが出来るってのが嫌だけど)
logpathはログファイルパスの指定で、何も指定しなかったらWebSphereならプロファイル直下に出来る。まあ、ヒープダンプと同じ扱いですかね。
出力ファイルは、log-rt.l_pidで、pidにはプロセスIDの数字が入る。このlog-rtのファイルは、後でVisual Performance Analyzerで読み込めるのだが、読み込む際に末尾に.jprofってリネーム(追加)することを求められるので覚えておくように。
classfileの指定は、僕はまだ試してない。アプリケーションサーバに仕掛ける場合、書かなくてもいける。
（むしろ書いたらアプリケーションサーバは動かない気がするんだけど・・・）
Java Object Profiling with Full Call Tree
java -agentlib:jprof=calltree,objectinfo[,hr][,sobjs][,start][,logpath=path] classfile
calltreeもメトリックスの指定のエイリアスみたいで、nometricsを意味してます。
objectinfoはたぶんヒープを調べたい場合につけるんだと思う。
hrはhumanreadableの略で、人でも読めるようにするってんだな。たぶんhprofのformat指定でテキストを選んでいるような感覚かな。
sobjsは、separate objectsの略で、サイズの違いで同じクラスのオブジェクトを分けて扱うみたいだ。
まだこれらは試してないがなんとなく、僕がやりたいメソッドプロファイリングではなく、ヒープアナライズな内容に思えた。
Java Object Profiling with Reduced Call Tree
java -agentlib:jprof=scs=allocated_bytes[=nn],objectinfo[,hr][,sobjs][,start][,logpath=path] classfile
なんだかだいぶ難しくなったぞ。。。
scsはCallstack Samplingを意味している、頭文字あってないけどさ。
オブジェクトのアロケーション契機でデータを取るように変わるっぽい。メソッドの開始終了で取らない。
=nnは超巨大なアプリケーションにたいしてプロファイルをする場合が使いどころのようだ。
Java Profiling via Monitor Events
java -agentlib:jprof=scs=monitor_contended_entered[+][=nn][,hr][,start][,logpath=path] classfile
これも取得契機な話っぽい。なんかどうでもよくなってきたな。
Java CallFlow (Generic/Gencalib)
java -agentlib:jprof=gencalib[,metrics=raw_cycles][,start][,logpath=path] classfile
java -agentlib:jprof=generic[,metrics=raw_cycles][,start][,logpath=path] classfile
どうも指定の仕方の違いによって、命令の集計の仕方が違うっぽい。
たぶんほとんどの場合gencalibでいい。gencalibのcalibは「calibrate」からきている。
メトリックスは何も指定しなければ、ptt_instsになるが、値を指定してraw_cyclesなんかにも変えられる。
出力ファイルはlog-gen.l_pidだ。
log-genもVisual Performance Analyzerで読める。
読み込めるのはlog-genかlog-rtであることを覚えておこう。
Record and Playback
まず使うことは無い。完璧なコールフロー収集により、完璧に再現するぜってことだ。
java -agentlib:jprof=callflow,record[,objectinfo][,start][,logpath=path] classfile
log-trace_pidファイルが出来るので、
java -agentlib:jprof=playback=pid
で再現出来るみたいだ。（あれ？ファイルのありかはデフォルトのみってことか？）
良く分からない部分がある。
Visual Performance AnalyzerのPDF資料を見ているとこんな指定もあるみたいだ。
java -agentlib:jprof=rtarcf classfile
ここのrtarcfは見たことがない。
Performs real-time call flow profiling and produce log-rt .
If rtarcf is specified, ptt_insts is the default.
何の略かは分からないが、リアルタイムでなんかやるっぽい。
log-rtに出力するのも分かるし、メトリックスのデフォルトも分かった。
んー、でもリアルタイムってどういうことかなー。
あとは、これもまだまだ勉強不足だが、Training Calibrationが大事っぽい。
なんかオーバーヘッドを加味するか何かだと思う。
java -agentlib:jprof=callflow,calstats=statfile,start trainer
calstatsオプションで、統計をcalcurateして、たぶんファイルを作るんだろう。
java -agentlib:jprof=callflow,usestats=statfile classfile
次にそのファイルを指定して使うのだろう。
trainerの使い方も載っているんだが、ちょっと面倒臭いな・・・。
rtdriverの使い方も覚えないといけない。
とりあえずローカルに繋ぐときは、
rtdriver -l
その後、startで収集開始。
flushで書きだし。
endは、flushとデータ収集の終了。
shutdownは、flushしてデータ収集も終了して、さらにjavaプロセスも落とし、rtdriverも終了。
Java Lock MonitorとかHeapdumpとかもあるけど、
それらは別の方法でやれてるから今はいいかな。
