VisualVM is practically the standalone Netbeans Profiler (which is a great tool, by the way).
But what I am missing, is the ability to initialize monitoring settings for a process before it starts.
Usually, in VistualVM, one can open a process and start changing settings only when the process is already running. This is a problem when one should want to profile a shorter-term process.
Sadly, this solution doesn't work: A Java program doesn't starts "fast enough", and gets suspended before it would be recognized by VisualVM as such.
Is it possible to do somehow?
NOTE 1: My current workaround: I added a cmd-line switch to my project: "-W" to wait for an [enter] key press.
NOTE 2: Strange, the Netbeans Profiler still gives much more realistic profiling results. But it has a bug currently, which forces me to recompile the main project the amount of times of linked projects ;) That'll be 12... And I failed to reproduce the bug.
Related
I have a frustrating issue where Eclipse (aka Spring Tool Suite flavor) falls into a strange build state that it can never complete or resolve. When the problem occurs, a cyclic state between multiple processes ensues. A common case is when the "Download Sources and JavaDocs" process runs every few seconds, dropping briefly into a "Sleeping" state to allow other processes to run, and then times out and restarts the process. This continues to repeat indefinitely. The switching from build to sleep modes perpetually occurs. These fighting processes will continue in this way for hours, if I let Eclipse continue, which also utilizes the CPU heavily throughout.
This unsettled state is often initiated when I perform a full clean and/or build of my project(s), whereas other times it happens when I include new Java Classes as required dependencies. Sometimes it gets going all on its own. Either way, Eclipse will vainly attempt to build the project(s) resources, and the project itself, and it will do so indefinitely without ever achieving a resolved state.
While there are a variety of combinations of these fighting / conflicting / deadlocked processes, I have noticed that it is often a "Building Workspace" process that frequently has issues. The build runs to around 85%, then suddenly sleeps while a "Download Sources" process appears and runs, after which the "Building Workspace" resumes once again... always starting over, and never quite building to completion. Always dropping into a sleep state when "Download Sources" runs.
When I grow weary of it, and wish to end it, I must either exit my IDE completely and restart, or I have to rapidly click the STOP button of the oscillating processes that that flash and disappear inconsistently in the progress view. It feels rather like playing a Whac-A-Mole carnival game of sorts, until I have successfully clicked them all. At that point, the processes cease to appear, and things run smoothly again for a time. This is NOT something that happens every time, but often enough to be a nuisance, and it interrupts productivity as it slows or blocks other processes, such as starting my project.
With previous builds of Eclipse on other machines, I never recall having this issue... at least not so persistently. And yet I have read similar issues in various forums (including Stack Overflow) going back for years.
Eclipse / Spring Tool Suite Version info
STS Version: 3.9.4.RELEASE
STS Build Id: 201804120921
Platform: Eclipse Oxygen.3a (4.7.3a)
HOST O.S.: Windows 10 - 64-bit edition
Here is what I have tried so far:
I unchecked the "Refresh using native hooks or polling" and my problem has continued to occur for the past few months.
I haven't moving the metadata folder out (article here) because I'm worried about wasting more time recovering if it goes wrong.
Disabled certain Maven plugins and closed projects. It does seem to happen less frequently when I have only a single project open. However, in the world of cooperating services, it is often necessary to keep multiple projects open.
Perhaps this is related more to the customized STS tooling (Spring Tool Suite) that has been applied over Eclipse, but because I'm not sure, I didn't Tag STS.
This issue is very intermittent, but once it starts happening, I can't get around it.
I'm trying to profile a junit test - all I care about is hot spots and call tree - I want to see where the test is taking time. I'm running the test by right clicking in intellij idea and saying "profile ..." The test runs in less than a second, and then finishes - even if I can get there quick enough to click call tree and click start recording (haven't found any way of getting it recording immediately) - anything I haven't managed to open by the time it finishes is not available, saying things along the lines of "no data was received because the profiled JVM has terminated.
How do I right click and run a test, have it capture all call history and timings in such a way that I can browse it all once the test has completed? (or is there an alternative/better way of doing this?)
In the profiling settings, on the "Miscellaneous" tab, there is a setting called "Keep VM alive". If you select that check box, the VM will not terminate as long as the JProfiler GUI is connected to it.
Update 2017-11-28
Since JProfiler 10, this setting is no longer in the profiling settings, but in the startup dialog. Also, there is now an option to automatically save a snapshot when the JVM exits. This has the advantage of not blocking the test runner in the IDE.
In Java profiling, it seems like all (free) roads nowadays lead to the VisualVM profiler included with JDK6. It looks like a fine program, and everyone touts how you can "attach it to a running process" as a major feature. The problem is, that seems to be the only way to use it on a local process. I want to be able to start my program in the profiler, and track its entire execution.
I have tried using the -Xrunjdwp option described in how to profile application startup with visualvm, but between the two transport methods (shared memory and server), neither is useful for me. VisualVM doesn't seem to have any integration with the former, and VisualVM refuses to connect to localhost or 127.0.0.1, so the latter is no good either. I also tried inserting a simple read of System.in into my program to insert a pause in execution, but in that case VisualVM blocks until the read completes, and doesn't allow you to start profiling until after execution is under way. I have also tried looking into the Eclipse plugin but the website is full of dead links and the launcher just crashes with a NullPointerException when I try to use it (this may no longer be accurate).
Coming from C, this doesn't seem like a particularly difficult task to me. Am I just missing something or is this really an impossible request? I'm open to any kinds of suggestions, including using a different (also free) profiler, and I'm not averse to the command line.
Consider using HPROF and opening the data file with a tool like HPjmeter - or just reading the resulting text file in your favorite editor.
Command used: javac -J-agentlib:hprof=heap=sites Hello.java
SITES BEGIN (ordered by live bytes) Fri Oct 22 11:52:24 2004
percent live alloc'ed stack class rank self accum bytes objs bytes objs trace name
1 44.73% 44.73% 1161280 14516 1161280 14516 302032 java.util.zip.ZipEntry
2 8.95% 53.67% 232256 14516 232256 14516 302033 com.sun.tools.javac.util.List
3 5.06% 58.74% 131504 2 131504 2 301029 com.sun.tools.javac.util.Name[]
4 5.05% 63.79% 131088 1 131088 1 301030 byte[]
5 5.05% 68.84% 131072 1 131072 1 301710 byte[]
HPROF is capable of presenting CPU usage, heap allocation statistics,
and monitor contention profiles. In addition, it can also report
complete heap dumps and states of all the monitors and threads in the
Java virtual machine.
The best way to solve this problem without modifying your application, is to not use VisualVM at all. As far as other free options are concerned, you could use either Eclipse TPTP or the Netbeans profiler, or whatever comes with your IDE.
If you can modify your application, to suspend it's state while you setup the profiler in VisualVM, it is quite possible to do so, using the VisualVM Eclipse plugin. I'm not sure why you are getting the NullPointerException, since it appears to work on my workstation. You'll need to configure the plugin by providing the path to the jvisualvm binary and the path of the JDK; this is done by visiting the VisualVM configuration dialog at Windows -> Preferences -> Run/Debug - > Launching -> VisualVM Configuration (as shown in the below screenshot).
You'll also need to configure your application to start with the VisualVM launcher, instead of the default JDT launcher.
All application launches from Eclipse, will now result in VisualVM tracking the new local JVM automatically, provided that VisualVM is already running. If you do not have VisualVM running, then the plugin will launch VisualVM, but it will also continue running the application.
Inferring from the previous sentence, it is evident that having the application halt in the main() method before performing any processing is quite useful. But, that is not the main reason for suspending the application. Apparently, VisualVM or its Eclipse plugin does not allow for automatically starting the CPU or memory profilers. This would mean that these profilers would have to be started manually, thereby necessitating the need to suspend the application.
Additionally, it is worth noting that adding the flags: -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=y to the JVM startup will not help you in the case of VisualVM, to suspend the application and setup up the profilers. The flags are meant to help you in the case of profilers that can actually connect to the open port of the JVM, using the JDWP protocol. VisualVM does not use this protocol and therefore you would have to connect to the application using JDB or a remote debugger; but that would not resolve the problem associated with profiler configuration, as VisualVM (at least as of Java 6 update 26) does not allow you to configure the profilers on a suspended process as it simply does not display the Profiler tab.
This is now possible with the startup profiler plugin to VisualVM.
The advice with -Xrunjdwp is incorrect. It just enables debugger and with suspend=y it waits for debugger to attach. Since VisualVM is not debugger, it does not help you. However inserting System.in or Thread.sleep() will pause the startup and allows VisualVM to attach to your application. Be sure to read Profiling with VisualVM 1 and Profiling with VisualVM 2 to better understand profiler settings. Note also that instead of profiling, you can use 'Sampler' tab in VisualVM, which is more suitable for profiling entire java program execution. As other mentioned you can also use NetBeans Profiler, which directly support profiling of the application startup.
My tomcat (version: 5.5.25) runs an application which I try to profile with VisualVM (ver: 1.3.2).
Everything looks nice but not all classes and methods are shown in visualVM. They ones that are missing run in thread [main]. I know this because this is the thread's name I receive if I a breakpoint has been hit. Classes which run outside main e.g. [worker1] , [worker2], ... are shown correctly.
Any idea what the reasons might be? Or what I could try?
Since the application I run (it is called Assentis Docbase) is closed-source they might have customized the default tomcat configuration. But they allowed me to extend the framework with my own classes and that are the ones I want to profile.
VisualVM I run with the default configuration as downloaded.
You probably need to customize profiling root methods. See Profiling With VisualVM, Part 1 and Profiling With VisualVM, Part 2. You can also use 'Sampler' tab to get high-level picture of what is your Tomcat doing.
Here are a couple of reasons why you may not be able to see the "main" thread:
The thread could have exited.
The thread could have changed its name by calling Thread.setName().
If you want to figure out the real reason, you will probably need to look at the Tomcat source code.
This page tells you where the settings are. Google is your friend.
The reason why VisualVM did not show my method calls in thread [main] is that VisualVM allows only to profile up to 32 threads simoultanously. It is NOT possible to allow more threads to be watched. This has been documented in Profiling With VisualVM, Part 2, section "Comparison With The NetBeans Profiler" they say:
"Profiled threads limit is always 32."
:-(
You've probably badly configured "Start profiling from classes" in the plugin config.
Say you've configured org.acme.competition.* (A) for profiling:
but you've accidentally profiled the class org.acme.reference.ReferenceImpl (B) using a command lie this:
$ cat source.txt | java -Xverify:none \
-agentpath:/usr/share/visualvm/profiler/lib/deployed/jdk16/linux-amd64/libprofilerinterface.so=/usr/share/visualvm/profiler/lib,5140 \
-cp bin/ org.acme.reference.ReferenceImpl
then this would be the wrong result:
When configuring VisualVM's Startup plugin config "Start profiling from classes" with org.acme.reference.* instead, the result is correct:
See the Startup profiler guide too.
I have a java application that its memory starting to jump and fall after few days.
Is there a tool that can show me the variables/members sizes during run/debug in real time?
Debugging it with eclipce is impossible.
Check out jhat and jmap.
In the longer run, consider adding a monitor to your app (with JMX, or write your own). It may help you in many situations in future.
Install this: http://visualvm.java.net/eclipse-launcher.html and then launch using Eclipse. This does not use the debugger, but launches the VisualVM application which lets you monitor the app. You'll need to go into the Run Configurations.. settings to set this up, and select VisualVM launcher at the bottom (Select Other... -> VisualVM launcher). You'll need to go into Preferences to set up the location of VisualVM too.
(On later Eclipse versions, drop it into the drops folder, unpacked).
If you're using >JDK6 and can get access to the machine then jvisualvm.exe may work, part of the JDK (in the bin dir)
yourkit (http://www.yourkit.com/) can do that, but expect a HUGE degradation on the performance of the app, as it has to track the size of each object.
I think it's better if you run yourkit with a few less invasive options, and then you can take snapshots of the memory usage.
I forgot to add, that with yourkit you can run the application without almost any instrumentation (which will slightly degrade the performance of the app) and when the problems start ocurring, you can enable the more heavy weight profiling while the app is running.