tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Eggers <its_toas...@yahoo.com>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Mon, 15 Apr 2013 15:18:02 GMT
On 4/15/2013 7:25 AM, David kerber wrote:
> 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.
>

Yep, there's no history in that data.

What you can do (probably in a test environment) is the following:

1. Set up monitoring (visualvm, psi-probe, jconsole)
2. Abuse your application with well-crafted JMeter (or other) tests
3. Watch memory

This becomes a little more challenging with AJAX-style applications 
(yours is a PrimeFaces / JSF / AJAX one, right?), but I've seen some 
notes on this. Google is your friend.

. . . . just my two cents.
/mde/


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


Mime
View raw message