Hi, Sun's JDK contains am small Java-App called 'jconsole'. You can run it remotely after configuring your tomcat like this: http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html (Enabling JMX Remote) Consider reading the JDK-docs also.
Real memory usage can be understood much better with this tool. You can even answer the permGen-question by yourself. And you learn that every reload causes a permanent increase in permGen-usage by some megabytes. (Interested in sending snmp-traps when reaching a specified memory limit? Look into it) And: no, we are not restarting tomcat every night. But you should really use some coutinous availabilty check tool (cron with wget, or jmeter) Try it! R. Am Mittwoch, 29. März 2006 20:03 schrieb Mark Hagger: > As I'm sure you know this is something of a large can of worms... > > All I can say is that from my experience of this modern JVM's are getting > much better at working well with the default gc options (ie jdk 5.0 and > above). We use jrockit for our systems, and just use a simple: > > -server -Xms256m -Xmx1024m > > Our server are dual processor boxes with 6Gig ram and all runs well for us. > From what I understand both current jrockit and sun gc strategies are to > delay gc work until as late as possible (jrockit seems to leave it later > than sun tbh). This tends to mean that memory usage never really seems to > drops much, our servers run with jrockit having grabbed around 1.9Gig > memory all the time, but then seem to run happily with that for long > periods of time (ie weeks at a time). Both jrockit and sun default to > adaptive gc systems for "large" systems, which ought to get to the right > approach in due course. > > Having said that experience suggests that if the application churns memory > very fast (tomcat doesn't really qualify for that for us, but some of our > other apps do), using a two generational concurrent gc approach is best, > especially for jrockit. > > The other thing to note is that a call to System.gc() does very little in > some jvm's, I think its increasingly taken as a hint, and most gc's almost > ignore it. A real full gc is expensive and can cause heavy pauses, gc > systems tend to avoid it like a plague. > > Hope this is of some help, although I'd be interested to hear others > thoughts on this. > > Mark > > On Wednesday 29 March 2006 19:17, John Powers wrote: > > I am trying to tune an instance of tomcat running a single application. > > And have a couple different questions. > > > > > > > > I have read lots of faqs and webpages on the various types of garbage > > collectors. I get from most of these that it takes lots of tuning > > particular to each machine/server/application. > > > > > > > > My main question is why the memory allocated keeps climbing. If I > > have a fairly consistent number of users, then as some sessions are > > freed up, others are made. Wouldn't the amount of allocated level off > > at some point? When a full GC is started, why does it never go back down > > to a low number? At night, lets say when there are no users, why > > wouldn't a GC drop the memory down to what is used by just the bare > > minimum? > > > > > > > > Most faqs and webpages say to allocate as much memory as possible. How > > can you use the aggressiveHeap tag if tomcat is also trying to specify > > Mmx and Mms settings? Does anyone have an example memory settings for > > a tomcat running on a 2-4 chip machine with around 2G of ram? > > > > > > > > I understand for a JSP application that we need to keep our permHeap > > size large. What do you guys normally do for that? 128M? 256M? 512M? > > > > > > > > Is it common that a tomcat needs restarting nightly to free up memory? > > In all my other apps I've had with tomcat, I've never needed to do that. > > I've been trying to use the profiler yourkit, but am uncertain what is a > > valid object in memory and what is being held on unnecessarily. > > > > > > > > Thanks for any help you can provide. > > > > > > > > > > > > > > ________________________________________________________________________ > > This email has been scanned for all known viruses by the MessageLabs > > SkyScan service. > > ________________________________________________________________________ > This email has been scanned for all known viruses by the MessageLabs > SkyScan service. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
