On 17/05/2010 14:40, Ozgur Ozdemircili wrote: > Hi all, > > Thanks for all the answers. Since the company didn`t have any > monitorization I think the correct decision here would be to start > monitoring the tomcat servers and see what is happening.I really do not > have any control on the programming part I need to find out first what > is happening. > > Could you please share your experiences on this too? > > I am looking into 2 kinds of monitorization software: > > - Java Melody > - Jrockit Mission Control > > > The servers we are talking about are getting about 1.000.000 requests a > day making query the DB and returning xml to our clients. Before them we > have a F5 load balancing server that is sending the requests on one of > the 2 servers. > > In the attached file you can find catalina.out of 2 servers.
(The list often strips attachments.) Does the problem manifest regularly, after a period of time? Or does the problem occur when the site experiences high load conditions? p > Özgür Özdemircili > http://www.acikkod.org > Code so clean you could eat off it > > > On Mon, May 17, 2010 at 3:17 PM, Caldarale, Charles R > <[email protected] <mailto:[email protected]>> wrote: > > > From: André Warnier [mailto:[email protected] <mailto:[email protected]>] > > Subject: Re: MaxPermSize / Threads > > > > So, while I am not saying that there are not circumstances where a > 2 GB > > Heap is justified, it is still a very high number, and maybe you > should > > have a look at which application really needs so much space. > > Having an excessively large heap does not hurt, as long as it's not > so large compared to available RAM that it pushes the environment > into paging. GC times are not affected by the size of the heap, > just the number of live objects present in the heap. Being able to > run the apps in a smaller heap does allow you to deploy on a > cost-reduced platform, but that's about all. If the JVM is the sole > application on the box, you might as well give it as much RAM as > you've got (unless you want to run with compressed object pointers). > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE > PROPRIETARY MATERIAL and is thus for use only by the intended > recipient. If you received this in error, please contact the sender > and delete the e-mail and its attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
signature.asc
Description: OpenPGP digital signature
