Transcription

1 schuylkill.nws.noaa.gov Using JConsole Bradley McCune (Hydrologic Services Division) 3/15/2013 Description CHPS is composed of numerous services and components which, generally, run in the Java Runtime Environment (JRE) via Java Virtual Machines (JVM). Sometimes, it can be quite helpful to "see" what is happening inside of these JVMs during operations, but there is no built-in function for doing so in FEWS. Instead, we can use a Java tool called "JConsole" (Oracle Manual) which allows us to attach to a JVM currently in operation and review how it is managing system resources in the JRE. CHPS services/clients which operate in a JVM: Stand Alones Operator Clients Forecasting Shell Servers PiService Clients Associated FB cases and examples: Required RHEL Packages In order to run JConsole, you will need to have the Java 6 development package installed: java openjdk-devel.i386 The above is a shortened name, but it should work. If not, you can find the full package name by running: [root]$ yum provides */jconsole Running JConsole In order to start JConsole, you must be the same user as the user who started the target JVM. Therefore, if you wish to attach to a shell server process (started by user fews), you must be user fews when running the following command: [fews]$ jconsole Super easy, right? After running the above, you'll get a new window listing all of the available JVMs running on the local machine with the current user.

2 Select the JVM you wish to monitor with either the name or PID listed.

3 Here, you'll see 4 panels of graphs. The first one is most often what we are dealing with- the Java memory heap. Select the "Memory" tab at the top, and we'll get a blown-up version of this graph along with some extra bit of information.

4 Something to keep in mind- JConsole only displays data since it was started, and it will continue to display ALL the data unless you specify a different time period via the drop-down menu above the graph. So what else is going on in this tab? We have a giant graph of the JVM memory heap allocation over time, and it's pretty self explanatory. Look at the "Details" section below the graph. Item Description Time Used Committed Max Self explanatory Current heap space memory in use. Memory delegated to the JVM from the system. Usually, Java tries to predict requests for additional memory ahead of time and will commit more memory than is Used. In this way, the memory is already available should the JVM ask for more. The maximum amount of memory the JVM is allowed to request for its heap space. Configured via -Xmx in a number of different FEWS scripts. Might be slightly lower than the exact Xmx value.

5 GC Time **Important** If you are getting heap space/gc errors or times when the clients are operating very slowly, this could verify the reason. Things to Look for If Used = Max, look at GC Time When your used memory reaches the maximum allowable heap, the JVM attempts to find unnecessary Java objects and purge them to free up space; this is Garbage Collection (GC). In general, GC is not a bad thing and fundemental to the operation of the JVM. You see two GC forms in the GC Time line. PS Scavenge: Happens all the time and is pretty hidden from the user. As objects become old, they are simply removed from memory freeing it up to be used again. This form actually runs even when the maximum heap has not been reached. PS MarkSweep: Initiated when Used = Max. Much heavier operation than PS Scavenge and performance impact becomes greater with larger heap sizes. PS MarkSweep is what causes your JVM to stutter and become unresponsive at times. Review the number of collections and total time spent GC'ing. If the PS MarkSweep is in operation greater than 40% of the time you have been monitoring the JVM, then there could be a serious problem with the current memory settings or configuration of the client itself. (Requesting too many timeseries in a workflow or displaying too many segments in a given IFD window.) Example PS MarkSweep driven performance loss.

6 Notice the 45 minutes on PS MarkSweep for almost the entire JConsole session. Clearly, the JVM is spending nearly 100% of its time looking for ways to free up memory rather than actually performing tasks for the user.