I have a wicket+spring+hibernate application running on Jetty. When I start CPU profiling it with VisualVM (jdk 1.7.0_9) it first stalls for several minutes with console prints:
Profiler Agent: 250 classes cached.
Profiler Agent: 250 classes cached.
These lines are repeated around 20 times, then VisualVM says it has started instumentation and instrumented around 8000 methods.
Now after this I click a button on my web application and again the application completely hangs for few minutes while console prints out lines like:
Profiler Agent: Redefining 100 classes at idx 100, out of total 336
After this I get profiling results but they are pretty useless as almost 99.6% of the time is spent by
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run()
This makes VisualVM totally unusuable. Any guesses what could be the culprit here?
I'm running Jetty 8.1.2.v20120308
The Profiler tab of an application enables you to start and stop the profiling session of a local application. Profiling results are displayed in the Profiler tab. You can use the toolbar to refresh the profiling results, invoke garbage collection and save the profiling data.
Under the Local node in the Applications window, right-click the application node and choose Open to open the application tab. Click the Profiler tab in the application tab. Click Memory or CPU in the Profiler tab. When you choose a profiling task, VisualVM displays the profiling data in the Profiler tab.
Self Time: total time spent invoking this method. If a method was called twice, the self-time will be the sum of the time spent in each call excluding internal method calls.
What is VisualVM. It is a tool automatically available after JDK is installed. The executable file could be found on your <JDK installation folder>/bin as displayed below. In order to measure the performance of your application, it is necessary for the application to be recognized by VisualVM first.
The answer is to narrow the scope of what classes are being instrumented.
Click on the settings option in the profiler and look at "Do not profile classes" or "profile only classes". Be sure to exclude third party libraries that you don't want to examine. For example, I was using Jython in my app and the profiler was trying to instrument thousands of classes, likely including classes dynamically generated at runtime (not good).
I would suggest to start with CPU sampling first. Once you have an idea what is wrong, you can switch to profiling to get detailed information. Be sure to read Profiling With VisualVM, Part 1 and Profiling With VisualVM, Part 2 to get more information how to set up profiling of your Jetty server.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With