I am trying to use VisualVM to profile a Java (Sun JDK 1.6) standalone application. I have a scripted performance test environment, where I can run my application and get it to report some metrics I care about.
Is there some way to get JVM to collect some CPU profiling snapshot which I can later analyze with VisualVM?
I am looking for something similar to -XX:+HeapDumpOnOutOfMemoryError flag which writes a heap dump to disk just before an OutOfMemoryError is thrown.
There is the hprof tool built into the JVM (http://java.sun.com/developer/technicalArticles/Programming/HPROF.html) which allows you to capture basic profiling information, its dog slow and produces massive files.
VisualVM AFAIK does not yet have these abilities, but yourkit has the ability to do what you want though its agent, and programmatically.
Yourkit via agent line (-agentlib:yjpagent=onexit=snapshot)
http://www.yourkit.com/docs/80/help/additional_agent_options.jsp
Programmatically
http://www.yourkit.com/docs/80/api/index.html
As an aside I would suggest that you are careful with measuring CPU along with performance testing as it will definatly skew your results, have you considered looking at something like https://japex.dev.java.net/ around your core code ?
Related
I have to run a couple of java services on my machine to obtain a certain dev environment (and get my not-java-related work done)
java -Xmx400m -jar foo-app/target/foo-app-SNAPSHOT.jar
java -Xmx250m -jar bar-app/target/bar-app-SNAPSHOT.jar
...
To not run out of memory, I need to limit the memory usage. The default (512m afaik) ist too high for my machine so I lowered them somewhat (on a wild as guessing basis). Except for one, where I learned the hard way (crashed, even freezes, and thankfully some .pid error files left behind in the project folder...), that I better settle a little higher:
java -Xmx800m -jar doo-app/target/doo-app-SNAPSHOT.jar
Question: is there a way, to track memory usage of a certain app over time?
By some java command line parameter or even with ps -ae, htop or similar? (thus not fiddling in the source itself, remap garbage collectors, etc, etc)
I see plenty of numbers, but figuring out which belong to which java project running, and what could roughly indicate me a proper peak memory consumption (in a -Xmx___m sense)... I have no idea.
I work under Ubuntu-MATE 16.04, x64.
The best way to analyze memory consumption is a profiler. In your jdk there comes the jvisualvm profiler, which is absolutely sufficient for this task. A (lengthy) tutorial can be found here: https://engineering.talkdesk.com/ninjas-guide-to-getting-started-with-visualvm-f8bff061f7e7
Other approaches are basically shotgun-style -reduce the xmx and then generate load in the system and see if it runs oom. If you do NOT have a straight controll flow you have no way to predict the used memory.
We have an application using Spring Integration in its core, and have created performance tests to see what is the processing speed (msgs/sec) for different generated input types.
This process is automated, so whenever such test is run, a separate instance is created in cloud, and disposed after done & output artefacts copied.
What I want to do is to have those performance tests monitored during the run for basic system metrics -- CPU, memory, I/O, GC runs/time. Obviously, the result of this should be some CSV files with metrics readings (e.g., once or twice a second).
So my question is: Are there any good and configurable tools for these purposes?
I'm in the middle of investigation, but profiling tools I reviewed so far mainly require human interaction and are UI oriented.
An option I'm considering is writing a separate tool to access MXBean & use it to log such data during the performance tests. Just wondering if anything good is around.
Please note that this application is running in Tomcat, however for the performance tests we are only using Spring Integration's File endpoints.
Please also note, that 'switchable' component within application is also possible solution. However, I'm currently looking for application-agnostic external tools-first solution.
Command-line tools come to help for this kind of a scenario:
On a Linux/Solaris based environment:
Before you run/trigger your JVM for Spring based application, you can run tools like vmstat, sar in a background mode with its output redirected to a flat file - which helps capture CPU, Memory and other such statistics. Use top with options or mpstat to get thread-level statistics if you seem to be hitting a performance problem, to do bottleneck analysis.
Now run the JVM with arguments like printgc, -Xloggc to write JVM verbose output to a flat file or print gc statictics. Look under Debugging options section for JVM arguments in Java HotSpot VM Options for more options you need.
Tip: create a shell script combining both commands above to run at the same time and achieve your requirement.
On a Windows environment:
For OS statistics gathering on commandline, you could use typeperf or tracerpt (CSV supported).
Now run the JVM with arguments like printgc, -Xloggc to write JVM verbose output to a flat file or print gc statictics. Look under Debugging options section for JVM arguments in Java HotSpot VM Options for more options you need.
Jmeter is a tool to develop performance and scalability tests (defining http requests and being able to load the server with them) , but also has a plugin to allow for monitoring a target system for system metrics such as CPU utilization, memory utlization etc and also JMX type statistics:
Available JMX metric types:
gc-time - time spent in garbage collection, milliseconds (used method)
memory-usage - heap memory used by VM, bytes (method used)
memory-committed - heap memory committed by VM, bytes (method used)
memorypool-usage - heap memory pool usage, bytes (method used)
memorypool-committed - heap memory pool committed size, bytes (method used)
class-count - loaded class count in VM (used method)
compile-time - time spent in compilation, milliseconds (used method)"
Check http://jmeter-plugins.org/wiki/PerfMonMetrics/ for more details of this plugin.
I'm trying to run a performance test in multiple databases, reading the info from a csv file, but after a while the Jmeter failed the test cases, because it rans out of memory.
I tried to increased "java -XX:MaxPermSize=1024m -Xms3072m -Xmx3072m -jar Apache-JMeter.jar" in this way but I having the same result.
Also Jmeter is creating a mysql connection to 5 different databases.
I'll assume you have a 64 bit operating system and JVM and lots of RAM available.
You can't guess about these things. Better to get some data using a profiler. Use something like dynaTrace, JProfiler or, if you have an Oracle JVM, the Visual VM tool that ships with the JVM.
You can't figure out what the problem is until you have some data. Maybe you need to write your tests differently so you don't have so much data in memory all at once.
first things first, are you modifying those command lines in the jmeter bat correct? because based on your dump we should be able to see how much ram you are ACTUALLY using..
e.g.
java.lang.OutOfMemoryError: Java heap space Dumping heap to java_pid999999.hprof ... Heap dump file created [591747609 bytes in 1321.244 secs] in this case this means that I was using a jmeter configured with a xmx of 591747609 bytes aka 512mb of ram..
By this we can understand if your settings are even being applied..
If that's fine, anyway post some profiler info and we'll see..
but consider these points:
1) jmeter in guimode is a real bottleneck if you want to see what's the performance of your java application... consider switching to remote testing.
2) check best practice on jmeter configuration, there are some sub-optimal settings in jmeter which hogs WAY too much memory, and you might want to turn them off...
give us an update and we'll see what advice can be given.
Make sure that you
Run JMeter in non-GUI mode
Disable all listeners, especially View Results Tree and View Results in Table ones
Use CSV as results output format
Avoid queries producing large result sets
Use Post Processors and Assertions only when and where required
Use latest version of JMeter on 64-bit OS and using latest version of 64-bit JDK
If you still experience OOM errors you will need to either switch to machine having more RAM or consider distributed testing.
After I connect to weblogic process through JConsole, I see some overall statistics but not the method-wise breakup of performance (time required for each method/class). Besides, as of now, I don't see how particular methods may be profiled using JConsole. Am I looking at the right tool? Or should I go for JProfiler instead?
You are using the wrong tool.
JConsole is a montiring tool. It will help you look at metrics like classes loaded, Heap Space, Perm Space, Threads Live, Collections etc etc...
What you want to do is profiling, not monitoring, try jvisualvm you can find it under JAVA_HOME/bin right next to JConsole.
BE aware that these tools have limited capability, I believe jvisualvm will make it to profile an application up to 65k classes, if you want to go bigger you should try JProfiler, Netbeans Profiler, or Yourkit maybe even Solaris Studio. It all depends on your platform and taste.
i am trying to analyze the CPU usage for a Java UI application running on Windows. I connected it to VisualVM, but it looks like the highest percentage for CPU usage is being used by
sum.rmi.transport.tcp.TCPTransport$ConnectionHandler.run();
I believe this is being used to supply information to VisualVM and hence VisualVM is skewing the results that i'm trying to investigate. Does any one have a way to get a better indication of what is occurring or a better method to determine what in a running java application is taking up so much CPU.
Try to use sampler first.
For detailed information use the profiler and set root methods. See Profiling With VisualVM, Part 1 and Profiling With VisualVM, Part 2 for more information about CPU and Memory profiling.
That sounds awfully suspicious. Try cross referencing the data with results from hprof. You won't need any external applications running, and the data will simply be dumped to a text file from your own process. Are you connecting to your process remotely?