tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David kerber <dcker...@verizon.net>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Mon, 15 Apr 2013 11:40:44 GMT
On 4/14/2013 11:10 PM, Howard W. Smith, Jr. wrote:
> 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.

Make sure you give it enough time for the memory use to stabilize. 
Depending on your app and usage patterns, it can take up to days for the 
sawtooth to stabilize and start showing.  One of mine takes a couple of 
hours, and another a few days for that pattern to become visible.


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


Mime
View raw message