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 19:49:13 GMT
On Mon, Apr 15, 2013 at 11:18 AM, Mark Eggers <its_toasted@yahoo.com> wrote:

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

Agreed!  :)


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

Interesting. I will have to try that, at some point. Thanks.


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

Yes, PrimeFaces, but not much AJAX at all. my endusers went from using an
almost 20-year-old MS-DOS dBase IV app to a Java/JSF web application. They
don't need AJAX (partial page refreshes), so they are very happy with full
page refreshes. :)

I implemented security and session management in my app via some approaches
that I got from BalusC on stackoverflow.com. so, Full page refresh (FPR) is
necessary to refresh the page,

<meta http-equiv="refresh"
content="#{session.maxInactiveInterval};url=#{pf_usersController.isLoggedInViaAndroid()
? 'pf_viewExpiredOnMobile.jsf' : 'pf_viewExpired.jsf'}" />

so, session can timeout/expire according to the follow context param, set
in web.xml.

    <!-- session-timeout = 15 minutes -->
    <session-config>
        <session-timeout>
            15
        </session-timeout>
    </session-config>

this meets my requirements for session timeout/expire/management.



> . . . . just my two cents.
> /mde/
>
>
>
> ------------------------------**------------------------------**---------
> 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