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 14:10:08 GMT
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



>
>
> ------------------------------**------------------------------**---------
> 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