tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Mon, 15 Apr 2013 03:10:00 GMT
On Sun, Apr 14, 2013 at 10:52 PM, Mark Thomas <markt@apache.org> wrote:

> On 14/04/2013 21:53, Howard W. Smith, Jr. wrote:
>
>> On Sun, Apr 14, 2013 at 6:51 PM, Christopher Schultz <
>> chris@christopherschultz.net> wrote:
>>
>>  -----BEGIN PGP SIGNED MESSAGE-----
>>> 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 <
>>>> chris@christopherschultz.net> 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.
>
> HTH,
>
> Mark
>
>
Interesting, that does help, Mark, thanks. 250 x 5 = 1,250. I guess I was
pretty close on target when I set Xms/Xmx = 1024m.

Prior to seeing your email/response, I checked the server again, and it was
no saw-tooth at all, it was at 250 (bottom), and then saw-tooth graph came
into play...minutes later.

Thanks again!



> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<users-unsubscribe@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message