I'm looking for a way to measure the cpu usage for different methods in my java code. I understand that this can be achieved using JNI and C, but I wouldn't know where to start...
The purpose of this is to compare different algorithms, and provide qualitative results.
Probably the most common way is to use sampling. The JVM provides facilities to ask it the current stack trace of all threads (or ones you're interested in), along with how much CPU they've consumed. So you periodically do this. On each call, if a thread is inside the method you're interested in, then assume that it's spent half of the reported CPU time since the last poll inside that method.
If this method sounds appropriate, a little while back I wrote some material on the Java 5 profiling facilities that might help you.
Java 5 also provides an Instrumentation framework, by which you can doctor classes as they're being loaded in to include calls on the entry and exit to your given method, so you can measure CPU usage just inside that method. However, this is a little more complex to program because you need to doctor the actual class binaries as they're being loaded.
I don't think you can really identify CPU usage down to the method level with the current range of profilers. For most methods it's pretty obvious (if the method is compute-bound and single-threaded then it'll use 100% of CPU subject to allocation by the OS).
You may want to identify hot-spots though (methods consuming more CPU than you'd anticipate - or possibly less?) and I'd recommend looking at YourKit for an easy-to-configure profiler.
Failing that, take a look at the JVM Profiling Interface (JVMPI), which may give you some further pointers.
Sun VisualVM is integrated in recent JDK's and its profiling capabilities are explained here. Note that it seems to require a pretty up to date version of OSX if I understand this correctly.
Netbeans has basically the same profiling machinery on board, I don't know if that's of any help.
If you want to use one of already available profiling tools, then you can try Shark
Have a look at the OperatingSystemMXBean perhaps you could look at something before and after your method
long startProcessCpuTime = operatingSystemMXBean.getProcessCpuTime();
long endProcessCpuTime = operatingSystemMXBean.getProcessCpuTime();
Java6 only
I I'm not sure if this is what you want but I've used jrat for profiling in the past with decent results.
Check JaMon. Is very easy to use.
Call your methods in separate threads and measure the delta of time before and after execution of given procedure.
To measure the time of a process call:
ManagementFactory.getThreadMXBean().setThreadCpuTimeEnabled(true);
long threadTime = ManagementFactory.getThreadMXBean().getCurrentThreadCpuTime();
Related
I am hoping to do a profiling analysis on my Java project. To get the results I want to add a "hook" to the JVM so that every time a heap access occurs, the "hook" is called and does some tracing. I have been looking into JVMTI but this does not seem to give me what I expect.
I have several questions:
Is it possible to add such a hook?
If possible, what are the correct tools/interfaces that I should use?
If there is no existing tools that do this, can I achieve this by modifying the JVM codebase?
Thanks.
I want to add a "hook" to the JVM so that every time a heap access occurs
You can't really do this in the Java as the hook itself would access the heap and cal itself. Even if you work around this, it would make the program impossibly slow.
What you can do is use the debugging interface to breakpoint after each instruction, inspect the instruction and see if it accessed the heap or not. This would be perhaps 10,000x slower than normal.
An alternative is to translate the bytecode using Instrumentation to trace each memory access. This might be only a few hundred times slower.
To do what you propose efficiently, you could use https://software.intel.com/en-us/articles/intel-performance-counter-monitor which used by tools such as perf on Linux. This requires in-depth knowledge of the processor you are using
I am a beginner in java. My requirement is to develop an agent application which check whether a system (CPU) is in good health to handle/run more java applications(There are several CPU’s available to run a java application. So, we should select the most healthy CPU according to its performance ).
What are the factors should I consider to check the CPU health? I already included RAM and CPU load to check CPU health.
*Is it possible to check the Heap memory ,I am getting the Heap usage of the current running program. Is there any way to find Heap memory used by all programs together run in Java Virtual Machine?
*Can I use number of Threads here?
Thanks in advance.
You're talking about task scheduling. This is a complex problem. Unless your project's core value lies in better CPU scheduling, I really recommend you rely on the operating system's scheduler instead, which likely has been improved over years or decades. This makes the endeavor very simple and you can ask more specific questions about how to influence the system's scheduler using Java APIs.
You'll want to look at the Java threading API and other concurrency-related packages.
If you really think you can get some benefits from very simple ("naive") scheduling, make sure to test all your scenarios to confirm. Often you'll encounter unexpected ramifications to your heuristics that may make things worse.
If you're an expert in task scheduling and your project's core value does lie in better scheduling, I suggest you rephrase your question to make it more explicit that you're looking for Java-related features. Note that the JVM is quite abstract, it might not provide the flexibility you require.
If you're not an expert in task scheduling and your project's core value still lies in better scheduling, I guess you're in for a nice ride. I suggest starting with thicker resources and asking more specific questions on SO or other places as you encounter them.
Good luck.
I am planning to micro benchmark my java code which involves several calls to local as well as remote database. I was about to use System.nanoTime() but started reading about the micro benchmarking frameworks such as jmh and caliper. Use of these frameworks is definitely recommended but from whatever (little) I read, it seems that we can benchmark only a complete method and also it allows us to do this non-invasively (w.r.t existing code) i.e., we need not litter existing code with the code/annotations of jmh/caliper.
I want to benchmark only specific pieces of code (statements) within some methods. Is it possible to do this with any of micro benchmarking frameworks? Please provide some insights into this.
I guess, calls to a DB are usually expensive enough to eliminate most of the problem with microbenchmarking. So your approach was probably fine. If you're measuring it in production, repeating the measurement many times, and don't care about a few nanoseconds, stick with System.nanoTime.
You're doing something very different from microbenchmarking like e.g. I did here. You're not trying to optimize a tiny piece of code and you don't want to eliminate external influences.
Microbenchmarking a part of a method makes no sense to me, as a method gets optimized as a whole (and possibly also inlined). It's a different level.
I don't think any framework could help, all they can do in your case is automate the work, which you don't seem to need. Note that System.nanoTime may take several hundreds cycles (which is probably fine in your case).
You can try using metrics from codehale.
I found its easy to use and low overhead if you are using in certain configuration i.e. Exponentially decaying Reservoir.
Micro level and precise benchmarking does comes with an associated cost with it i.e. memory overhead at run time for sampling, benchmark might it self take time for calculation and and stats generation (ideal one would be offsetting that from stats) .
But if you want to bench mark db connection which I don't think should be very frequent, metrics might be appropriate, I found its easy to use. and yes it is bit invasive but configurable.
Is it possible that attaching a profiler to a JVM (let's say VisualVM) could make some methods run slower, while not effecting others and thus causing a skew in the results that makes it look like a certain piece of code is a hotspot when in fact it's not. I will ask specifically about reflection calls for an example. I'm running some code that shows a lot of time spent in Spring AOP calls (specifically invokeJoinpointUsingReflection) - which the author says runs fine in testing (using an in code microbenchmark) but when they profiled it showed this method to take longer then other non-reflection methods. (sorry if that' a little unclear) So it got my wondering if the profiler could really have this effect and lead a developer down a false trail. Feel free to answer with any examples, the reflection part is just my example.
Profilers regularly give mis-leading information, but in generally they are usually right. Where they tend to skew the result is in very simple methods which might be further optimised if profiling wasn't enabled.
If in doubt I suggest you use another profiler, such as YourKit (evalation version should be fine) It has more light weight recording, but can have the same issues.
Heisenberg famously observed that collecting information from a system always disturbs it, so you can't get an undisturbed observation. (Thus the software term, "Heisenbug"). Yes, collecting profiling information can cause the actual performance to be changed in ways that will misdirect you.
Whether that is true in a significant way for your particular JVM or profiler, and how much disturbance occurs, is a matter of engineering.
Most profilers are sample based, and thus the more data you collect, the more accurate the results are. As far as I know, there is no bias for or against methods written purely in Java.
Certain profilers require a calibration step, e.g. NetBeans and VisualVM. You might verify the vintage and settings for your chosen profiler.
Is there any Java profiler that allows profiling short-lived applications? The profilers I found so far seem to work with applications that keep running until user termination. However, I want to profile applications that work like command-line utilities, it runs and exits immediately. Tools like visualvm or NetBeans Profiler do not even recognize that the application was ran.
I am looking for something similar to Python's cProfile, in that the profiler result is returned when the application exits.
You can profile your application using the JVM builtin HPROF.
It provides two methods:
sampling the active methods on the stack
timing method execution times using injected bytecode (BCI, byte codee injection)
Sampling
This method reveals how often methods were found on top of the stack.
java -agentlib:hprof=cpu=samples,file=profile.txt ...
Timing
This method counts the actual invocations of a method. The instrumenting code has been injected by the JVM beforehand.
java -agentlib:hprof=cpu=times,file=profile.txt ...
Note: this method will slow down the execution time drastically.
For both methods, the default filename is java.hprof.txt if the file= option is not present.
Full help can be obtained using java -agentlib:hprof=help or can be found on Oracles documentation
Sun Java 6 has the java -Xprof switch that'll give you some profiling data.
-Xprof output cpu profiling data
A program running 30 seconds is not shortlived. What you want is a profiler which can start your program instead of you having to attach to a running system. I believe most profilers can do that, but you would most likely like one integrated in an IDE the best. Have a look at Netbeans.
Profiling a short running Java applications has a couple of technical difficulties:
Profiling tools typically work by sampling the processor's SP or PC register periodically to see where the application is currently executing. If your application is short-lived, insufficient samples may be taken to get an accurate picture.
You can address this by modifying the application to run a number of times in a loop, as suggested by #Mike. You'll have problems if your app calls System.exit(), but the main problem is ...
The performance characteristics of a short-lived Java application are likely to be distorted by JVM warm-up effects. A lot of time will be spent in loading the classes required by your app. Then your code (and library code) will be interpreted for a bit, until the JIT compiler has figured out what needs to be compiled to native code. Finally, the JIT compiler will spend time doing its work.
I don't know if profilers attempt to compensate to for JVM warmup effects. But even if they do, these effects influence your applications real behavior, and there is not a great deal that the application developer can do to mitigate them.
Returning to my previous point ... if you run a short lived app in a loop you are actually doing something that modifies its normal execution pattern and removes the JVM warmup component. So when you optimize the method that takes (say) 50% of the execution time in the modified app, that is really 50% of the time excluding JVM warmup. If JVM warmup is using (say) 80% of the execution time when the app is executed normally, you are actually optimizing 50% of 20% ... and that is not worth the effort.
If it doesn't take long enough, just wrap a loop around it, an infinite loop if you like. That will have no effect on the inclusive time percentages spent either in functions or in lines of code. Then, given that it's taking plenty of time, I just rely on this technique. That tells which lines of code, whether they are function calls or not, are costing the highest percentage of time and would therefore gain the most if they could be avoided.
start your application with profiling turned on, waiting for profiler to attach. Any profiler that conforms to Java profiling architecture should work. i've tried this with NetBeans's profiler.
basically, when your application starts, it waits for a profiler to be attached before execution. So, technically even line of code execution can be profiled.
with this approach, you can profile all kinds of things from threads, memory, cpu, method/class invocation times/duration...
http://profiler.netbeans.org/
The SD Java Profiler can capture statement block execution-count data no matter how short your run is. Relative execution counts will tell you where the time is spent.
You can use a measurement (metering) recording: http://www.jinspired.com/site/case-study-scala-compiler-part-9
You can also inspect the resulting snapshots: http://www.jinspired.com/site/case-study-scala-compiler-part-10
Disclaimer: I am the architect of JXInsight/OpenCore.
I suggest you try yourkit. It can profile from the start and dump the results when the program finishes. You have to pay for it but you can get an eval license or use the EAP version without one. (Time limited)
YourKit can take a snapshot of a profile session, which can be later analyzed in the YourKit GUI. I use this to feature to profile a command-line short-lived application I work on. See my answer to this question for details.