Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4C618343.5030506@christopherschultz.net>
Date: Tue, 10 Aug 2010 12:50:11 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US;
 rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: [OT] Tomcat unexpectedly shuts down
References: 
 <SNT128-W26D6415B44B8007DDEC591A2940@phx.gbl>,<99C8B2929B39C24493377AC7A121E21F99011AA516@USEA-EXCH8.na.uis.unisys.com>,<SNT128-W269905F5623D098C82C78FA2940@phx.gbl>,<99C8B2929B39C24493377AC7A121E21F99011AA6B5@USEA-EXCH8.na.uis.unisys.com>
 <SNT128-W62D6D2841A8765E1D69436A2940@phx.gbl> <4C607F1A.4030802@ice-sa.com>
In-Reply-To: <4C607F1A.4030802@ice-sa.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 8/9/2010 6:20 PM, André Warnier wrote:
> I must say that your 3000 MB of Heap kind of makes my head spin.  What
> kind of application are you running that you would think you need as much ?

Are you saying that "___ of memory ought to be enough for anyone"? ;)

Obviously, /someone/ must need that kind of memory sometimes, otherwise
there would be no reason to have machines that can have that amount of
memory.

Seriously, though, there are a lot of reasons you might want to have a
relatively large heap for a webapp:

1. Session data can really pile up, especially if you have a /lot/ of
   concurren users or large amounts of session data (or both). 3000
   simultaneous users (not requests) isn't that crazy. If they all have
   1MiB of session data... there you go. Obviously, you can "squeeze the
   balloon" at either end and the other side grows.

2. Caches. This may be something that is often not considered for a Perl
   hacker such as yourself, where webapps tend to be scripts that run
   once and then terminate. Since the servlet context is always
   available and is (relatively) persistent, the opportunity for caching
   is quite high. If you can cache static data in the application
   instead of, say, reading from the database every time, you can
   improve performance dramatically.

   Even user-data caches can help quite a bit, whether they go into
   the session (see above) or the application scope.

3. Per-request data requirements might be high. For instance, if XML
   documents (notorious memory killers) must be parsed in totum
   (say, using a DOM parser or the like, rather than streaming, such
   as with a SAX parser) during the request, the amount of memory
   needed at any particular moment might be quite large, even though
   the memory might be freed immediately after the request has been
   processed. Since one never wants to suffer an OOME, you need to
   plan for peak service: that is, all 3000 of your users requesting
   an XML document operation all at once.

I'm sure there are other reasons, but those were the ones that
immediately came to my mind.

In our primary production application, we were running with a 64MiB
fixed-size heap for about 5 years. One day, we got an OOME and I freaked
out. Subsequent analysis showed that we simply needed a bigger heap to
support the growing number of users we were serving (always a positive
thing!). We grew to 192MiB, just in case ;)

The point is that some webapps, or some webapps in some environments,
just need massive amounts of heap space. The data's got to live
somewhere, right?

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxhg0MACgkQ9CaO5/Lv0PAjzQCgh9+v/0bgJZsIIjl39xEFZWO5
c08AoIqw4icImUllbstvEMMExDQOk8gL
=hx4b
-----END PGP SIGNATURE-----

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