Re: Get performance statistics?
Chris Uppal wrote:
Patricia Shanahan wrote:
Either way, I'm afraid it is going to be less convenient than my current
lifestyle - one makefile to control the runs, one Jar file to contain my
program, and it all works on my home system, works on my university
desktop, and runs dozens of jobs in parallel on a large grid computer.
Then it might be easier to use the Java-native JMX interfaces to the same (I
assume) features as JVMTI. See java.lang.management.ThreadMXBean.
I have never used it myself, so I don't know what lurking problems there may
be, but I'd guess it's worth spending a little time on it in the hope of
avoiding JVMTI or (worse) OS-specific JNI code.
Thanks! That looks like just the sort of thing I was looking for. I'll
have to do tests to see whether the features I need are supported, but
since both MS-Windows and Linux have the OS features to support it, I
would expect it to work.
If that works out, I can get my ideal, a performance record in the XML
output from the program.
But -- just a thought -- I'd have expected the target grid computer(s) to have
monitoring built-in for all this kind of thing. If that already exists, then
you can presumably activate and collect it as part of your "job submission" (or
whatever the modern equivalent is); so there's be no need to replicate it in
your other environments. The parsing code would run on, say, your home machine
just the same as on the grid machine, but it'd be reading dummy data for
testing.
I do production runs on every machine I use. If I just need a couple of
results from smallish jobs, it isn't worth while creating a session on
the grid's control node and transferring files around. On the other
hand, when I need 200 runs or a job that hits out-of-memory if -Xmx
specifies less that 1500m, the grid is the place to be.
Patricia