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 14:25:05 GMT
On 4/15/2013 10:10 AM, Howard W. Smith, Jr. wrote:
> On Mon, Apr 15, 2013 at 7:40 AM, David kerber<dckerber@verizon.net>  wrote:
>
>> 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.
>
>
> Will do (and doing that), thanks.  :)
>
>
>> 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.
>
>
> I see it stabilize 'in minutes' (after/during usage of the app).
>
> Just now (prior to writing this email), I was looking at the app's usage
> (via monitoring the app's own data/record audit trail page), and then
> decided to check-on the app to see how it is doing/performing via
> jvisualvm, and voila, again, I saw no saw-tooth[1].
>
> I saw this, 5 to 15 minutes after a period of inactivity in the app, but
> before I logged into the app, as I stated above, I checked the app's audit
> trail (which can definitely be a 'heavy-lifting' database query, depending
> on work done within the app on selected date, default = current date), and
> it[1] still showed no activity (or saw-tooth); I assume activity within the
> app can = definite/obvious saw-tooth graph (which also means, GC is working
> while app is being used).
>
> What I mentioned above is very normal behavior for my app.
>
> [1] http://img805.imageshack.us/img805/8453/20130415jvisualvm01.png

These graphs are only showing ~40 seconds of data.  I'll bet if you let 
the app run for several minutes or hours, you'll see it.



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


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


Mime
View raw message