Hey,

I am interested in performance measurements (CPU and disk I/O demands) of Java EE applications.

For CPU I already figured out how to measure the CPU demand of each method invocation. By invoking java.lang.management.ThreadMXBean.getCurrentThreadCpuTime() at the beginning and at the end of each method (e.g. using an EJB interceptor) I can get the ("pure") time which the CPU needed for processing this method (CPU Demand).

Unfortunately, the I/O demand (disk: read and write time for each method invocation) seems to be really hard to measure. The ThreadMXBean does not provide such data. Just substracting the above measured CPU demand from the complete response time of each method is not sufficient due to Suspension and Sync time (also it would be nice to distinguish between read and write if possible).

I was thinking about digging further down to the Operating System interfaces to try to invoke Syscalls or parse other kernel information. Currently I am trying to understand how tools like "sar" measure the "iowait" time and how I could map such data to my Java threads and respective methods. But I am not sure if I am heading in the right direction as my deeper OS knowledge is limited.

Long story short: How can I measure I/O Demand (disk read and write times) for each of my thread's method invocations?

Thanks in advance, bkk

Long answer short: you can't.

CPU usage is by definition assigned to a particular task on a specific CPU(/core). I/O is issued and then amalgamated by the I/O schedulers. Some time later the physical I/O takes place. All you can get is averages - that is what sar and similar tools offer.

Direct I/O is different, but the app has to manage that - and then, again by definition - knows the numbers.

1 members found this post helpful.

Thank you very much for your answer, syg00!

So, for an arbitrary thread (ignoring Java/JVM specifics) running on my linux system there is no system API I could use for determining the thread's I/O (disk) demand?

Do you mind giving me some hints how to research this topic further? You already mentioned the I/O scheduler. Maybe there is a way to approximate the I/O demands for each thread.


Thanks in advance, bkk

Correct - sortof.
Everyone in the discussion (you, me, the kernel, tool authors ...) need to have very precise definitions of what they want/provide. "the thread's I/O (disk) demand" for instance. I/O rate (per second - aka IOPS) ?, response time (per I/O) ?, average response time ?, delay time (per I/O), delay percentage, ... ?
Some of these are available, some require specific options at kernel compile time, some require inserting/activating probes into the running kernel functions.Historically Linux maintains stats in /proc - this is a virtual filesystem that exists in kernel cache, not disk. You read /proc/<whatever>, you get the current numbers, compare to your last read numbers and do the arithmetic. This is what most of the tools do for you. vmstat, top, whatever.
A while back taskstats was added to the kernel which does (some of) what the name implies. But all you get is averages, not exact per event durations. iotop is an example of a tool that exposes taskstats data and may give you enough. Your distro may or may not supply/support it as it requires said kernel options set. The Fedora devs didn't as they claimed they had measured too much overhead - which was bullsh1t. F22 appears to be the first to support it.
There is also a CPAN module to analyze taskstats data, but you need to get the data out first.

1 members found this post helpful.