tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Mon, 15 Apr 2013 02:52:42 GMT
On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
> On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz <
>> wrote:
>> Hash: SHA256
>> Howard,
>> On 4/11/13 10:38 PM, Howard W. Smith, Jr. wrote:
>>> On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz <
>>>> wrote:
>>>> Your heap settings should be tailored to your environment and
>>>> usage scenarios.
>>> Interesting. I suppose 'your environment' means memory available,
>>> operating system, hardware. Usage scenarios? hmmm... please clarify
>>> with a brief example, thanks. :)
>> Here's an example: Let's say that your webapp doesn't use HttpSessions
>> and does no caching. You need to be able to handle 100 simultaneous
>> connections that do small fetches/inserts from/into a relational
>> database. Your pages are fairly simple and don't have any kind of
>> heavyweight app framework taking-up a whole bunch of memory to do
>> simple things.
> Thanks Chris for the example. This is definitely not my app. I am
> definitely relying on  user HttpSessions, and I do JPA-level caching
> (statement cache and query results cache). pages are PrimeFaces and
> primefaces = xhtml, html, jquery, and MyFaces/OpenWebBeans to help with
> speed/performance.  And right now, the app handles on a 'few' simultaneous
> connections/users that do small and large fetches/inserts from/into
> relational database. :)
> Hopefully one day, my app will be support 100+ simultaneous
> connections/users.
>> For this situation, you can probably get away with a 64MiB heap. If
>> your webapp uses more than 64MiB, there is probably some kind of
>> problem. If you only need a 64MiB heap, then you can probably run on
>> fairly modest hardware: there's no need to lease that 128GiB server
>> your vendor is trying to talk you into.
> Understood, thanks. I have Xms/Xmx = 1024m, and I rarely see used memory
> get over 400 or 500m. the production server has 32GB RAM.

I'll summarize a number of JavaOne sesisons I've been to on GC and 
performance (caveat - this was a couple of years ago and GC design has 
moved on since then).

- GC pause time
- throughput
- small memory footprint

You can optimise for any two of the above at the expense of the third.

Assuming you opt for min GC pause time and max throughput the question 
then becomes how much heap do you need? If you look at your steady state 
heap usage graph (it should be a saw-tooth) then take the heap usage at 
the bottom of the saw-tooth and multiply it by 5 - that is the heap size 
you should use for the GC to work optimally.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message