Hi.
Tomorrow morning (European time), we are planning a moment of peak usage of one Java
daemon application. It is not Tomcat, but it behaves in a manner similar to Tomcat, in the
sense that it listens on a TCP port, processes quasi-HTTP requests, creates threads as
needed to process these requests, manages kind of sessions etc..
It is not our application and we do not have the source code.
Our biggest concern is the amount of memory it will use under the predicted high load, as
for each "session" it needs to parse and keep in memory the contents of a moderate-size
XML file.
We would like to monitor the memory usage of that JVM, but in a way that in itself does
not impact the performance too much. Basically what we want, is to keep some information
in a logfile, which in case of serious problem with memory would allow us to get a clue as
to what is happening via some post-mortem analysis.
So not just a dying dump, nor a nice GUI interface, but more in-between, like a trace log
that gives us some "snapshots" on a minute-by-minute base (on on a GC-cycle base) of the
evolution under load.
Preferably also, not something that takes a big effort to set up.
I am thinking of a couple of command-line options for the JVM, to dump for example some
information each time a GC happens, but among the array of available switches I do not
really know what to pick as a reasonable compromise.
Since this place is packed with Java gurus (what we are not), any quick
suggestions anyone ?
Thanks.
Oh, and here is the environment info :
# java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
The JVM of the application is started with "-Xms1024M -Xmx2048M", and no additional
non-standard GC-related options right now.
The host has a total of 12 GB RAM, of which only maybe half is really used for
now.
# uname -a
Linux vixen2 2.6.26-2-amd64 #1 SMP Tue Jan 25 05:59:43 UTC 2011 x86_64 GNU/Linux
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
