Java 1.6 JDK Tool, VisualVM

Question

Has anyone used the new Java 1.6 JDK tool, VisualVM , to profile a production application and how does the application work while being profiled?

The documentation says that it is intended to be used for both production and development, but based on previous profiling experience with other profiling tools, I hesitate.

Answer 1

Although I personally have not used VisualVM, I only saw this blog post today, which may have some useful information for you. He talks about profiling a production application using it.

Answer 2

I tried it in dev-dev and found that when I turn off profiling, it would suddenly turn off Tomcat. I would be very careful to translate this into production - can you simulate the load in an intermediate environment? This is not as good as the real thing, but it probably will not make you get fired if it goes wrong ...

Answer 3

I used VisualVM before to profile something running locally. The big win was that I just run it and it can connect to a working JVM. This is easier to use than other profiling tools that I used before, and there seems to be not much overhead.

I think he is sampling. The overhead of a processor-intensive application did not look significant. I didn’t measure anything (I was interested in how my application was executed, and not how the tool performed), but it definitely did not have a slowdown factor of 10, which I used to see from profiling.

Answer 4

For simple application monitoring, starting VisualVM remotely should not slow it down much. If the system is not on the verge of collapse, I still don't see any problems. It is basically just reading information from the coarse-grained embedded JVM toolkit. However, if you start profiling, you will have the same problems as with other profilers. Mostly because they all work almost the same way, often using support in the JVM.

Many people have problems starting VisualVM remotely due to problems with the firewall, but you can even start the visual virtual machine remotely via ssh , with some set of system properties.

Answer 5

It is possible to remotely connect to your server from another computer using VisualVM. You just need to right-click on the “Remote” node and say “Add Remote Host”.

This will at least eliminate VisualVM overhead (if any) affect performance while running.

This may not resolve all performance issues, especially in production environments, but it will help a bit.

Answer 6

I used the Net Beans profiler, which uses the same reinforcements as the Visual VM.

I was working with an older version of Weblogic, which meant using a 1.5 JVM, so I could not perform a dynamic join. The application that I was profiling had several thousand classes, and my workstation was largely unusable, and the profiler was all. After the toolkit was completed, the system was sluggish, but not completely unusable. The amount of slowdowns really depends on what you need to capture. The main indicators of the processor are quite light. Memory profiling slows down significantly.

I would not use it in a production system. In addition to the possibility of slowing down, I ended up running out of PermGen space, because the profiler of reinstalling and reloading classes when changing settings. (This can be fixed in the 1.6 agent, I do not know)

Answer 7

I often use VisualVM since it was not included in the JDK. This has an invaluable impact on system performance. I have never noticed that this causes performance problems on the system, but again, there was enough time on our Java server to support a small additional load. If your server is running at a level that is completely complete and cannot work with VisualVM, then I would say that it is more likely that you need to buy another server. Any production server should have some memory, otherwise what you have is just a disaster, awaiting its appearance.

Answer 8

I used VVM (VavaVoom?) Quite widely, it works like a charm in light mode, i.e. Does not profile, just getting basic data from the virtual machine. But as soon as you start profiling and there are many classes, there is a significant slowdown. I would not become a profile in a production environment, even if you have 128 baseboards with 2 memory teras just because reloading and redefining classes is difficult, server class loaders are another thing, they also vary from one server implementation to another, interfere to them in production is not a good idea.