subject:"Tomcat unexpectedly shuts down"

Re: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread André Warnier

Ok guys, my curiosity is satisfied in the absolute, and I know understand why one /could/ 
need a very large Heap size.


I would still like to hear the OP's answer however.
His questions led me to believe that he wasn't quite sure how much memory he needed just 
to run Tomcat.  Maybe he was horribly misinformed somehow or misread a number somewhere, 
or just copied the configuration of another Tomcat server without really realising what it 
meant.




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

RE: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread Caldarale, Charles R

> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: [OT] Tomcat unexpectedly shuts down
> 
> N.B. I was unable to get a predictable maximum heap size when 
> running with -Xmx:

You'll need to set -Xms and -Xmx to the same value if you want consistency and 
predictability.  Otherwise the default minimum and the adjustments made for the 
selected platform and GC algorithm kick in.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

Re: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread Christopher Schultz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 8/10/2010 5:31 PM, André Warnier wrote:
> It is just that 3000 MB is *a lot* of bytes (3,145,728,000 of them).

Yup. 3000MiB is even bigger (3,221,225,472 of them), and what you'll get
from the JVM. (See below)

> Which means that each time one of  these users hits the system, 
> Tomcat would need to read and load 1 MB of data just to retrieve
> this user's previous session data, without even having done anything
> yet for this user and his present request.

Maybe, but maybe not: the Java heap is usually entirely in memory, so
in-memory session data is very quickly accessed (or ignored, depending
on how the request is handled). There is no penalty for loading this
session data in this case. Unless otherwise configured, all session data
stays in-memory during the lifetime of the context. This isn't like PHP
(or Perl?) where the sessions are serialized every time a request
completes and de-serialized when a request begins (and the session data
must be fetched).

In the case where the session data is stored on disk or in a database,
the penalty for accessing data is highly dependent upon the strategy for
storage and retrieval: if the entire session must be fetched from
storage unconditionally, then yes, it is a giant waste of time if that
data is not used every time. Heck, it's a giant waste of time no matter
what. On the other hand, if session attributes are stored and accessed
individually, one may be able to get away with little to no overhead for
session attributes that one actually uses (and no overhead if the
session is not used).

> One may wonder how fast this server is expected to be, if it handles
> 3,000 user sessions simultaneously ?

3000 sessions isn't really that crazy when you think about it. 3000
simultaneous requests might be a bit heavy on a single, modest server.

> So let's say that I am just curious as to what the application is.

Agreed.

> Where I do object :
> 
> Christopher Schultz wrote: ...
>> 
>> 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.
> 
> Wrong.  I am also a mod_perl hacker. In a mod_perl environment,
> scripts (or handlers) do not "terminate", and memory is not recycled
> (this is even an inconvenient of mod_perl, and something to watch
> when designing mod_perl applications).

Apologies. I was thinking the .cgi-style scripts that I'm pretty sure
/do/ terminate. Use of mod_perl is outside the scope of my argument :)

> A secondary motive for my question to the OP, was to find out
> whether this size was really the result of a rational calculation
> (or experience), or just some number plucked out of the air. RAM
> prices are fickle, but let's say that for server-quality RAM, one 
> currently pays 25 US$ per GB. And we do not know who the OP works
> for, but say he is talking about 1,000 Tomcat servers.

That's 3TiB of RAM. Sweet.

> Saving 1 GB of
> Heap to run his applications would thus mean saving 25,000 US$. I
> believe it is worth asking the question.

Agreed.

- -chris

N.B. I was unable to get a predictable maximum heap size when running
with -Xmx:

public class MemoryInfo
{
public static void main(String[] args)
{
Runtime rt = Runtime.getRuntime();
System.out.printf("total=%10db (%4dMiB)", rt.totalMemory(),
(rt.totalMemory() / (1024*1024)));
System.out.println();
System.out.printf("  max=%10db (%4dMiB)", rt.maxMemory(),
(rt.maxMemory() / (1024*1024)));
System.out.println();
System.out.printf(" free=%10db (%4dMiB)", rt.freeMemory(),
(rt.freeMemory() / (1024*1024)));
System.out.println();
}
}

$ java -Xmx10M MemoryInfo
total=   9961472b (   9MiB)
  max=   9961472b (   9MiB)
 free=   9731320b (   9MiB)

Note that 9437184 (1024 * 1024 * 9) < 9961472, so I'm not sure why the
extra memory. The code above doesn't necessarily get /only/ heap memory,
but you get an extra 5% for some reason.

$ java -Xmx100M MemoryInfo
total=  64356352b (  61MiB)
  max=  93257728b (  88MiB)
 free=  64019480b (  61MiB)

That's weird: the JVM gives me less than I requested this time: only 88%
of what I requested.

$ java -showversion -Xmx1000M MemoryInfo
java version "1.6.0_20"
Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
Java HotSpot(TM) Server VM (build 16.3-b01, mixed mode)

total=  64356352b (  61MiB)
  max= 932118528b ( 888MiB)
 free=  64019480b (  61MiB)

... and again: less than I requested. Odd. Even when I use 1MB = 1024 *
1000, I'm still being stiffed by the JVM.

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

iEYEARECAAYFAkxhztUACgkQ9CaO5/Lv0PAXeACeP4uhSfDmw/GedynYNMvBqKUY
YdcAn09WBlQS8e16CUjo/wQQy+jqMP7x
=ENGs
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-

Re: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread David Fisher

Hi Andre,

> So I am not objecting to using 3000 MB of Heap, I am just curious.
> If someone like Eric Robinson can run a non-trivial multi-user Tomcat 
> application with an average 64 MB of Heap and you can do pretty much the 
> same, then I am curious as to which Tomcat application (or situation) may 
> require 3,000 MB of Heap, which is 50 times more.

I will give you an example of two reasons for a large heap -

(1) You host a large data set that you treat as a global in memory database 
achieving lighting quick sorts and filters across any column. This consumes a 
large amount of memory for the life of the JVM. Daily refreshes require double 
space in transition. The size of the heap will limit the size of the data set.

(2) You need to produce large Excel spreadsheets or Powerpoint decks using 
Apache POI. Due to the binary nature of the file formats everything is 
constructed in memory and the memory footprint of the Java objects is much 
larger. The XML versions don't give you any relief as they are Zip files. This 
means you need large amounts of space for short periods of time. Again more 
memory means the more head room you have for these requests. You have to know 
your app well to know if you have enough room for the very occasional large 
request. If that can be too big then you will need to build an execution queue 
of some type behind your web app.

Regards,
Dave
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread André Warnier

Christopher,

I have no fundamental contest with anything you say below (except one, see in
text).
It is just that 3000 MB is *a lot* of bytes (3,145,728,000 of them).
It is, for example, the number of letters contained in 3,000 books, each of 500
pages.
So even if you had 3,000 users, it would mean that the session data of each user would be
about 1,000,000 bytes (as you indicate yourself below). Which means that each time one of
these users hits the system, Tomcat would need to read and load 1 MB of data just to
retrieve this user's previous session data, without even having done anything yet for this
user and his present request. One may wonder how fast this server is expected to be, if
it handles 3,000 user sessions simultaneously ?

So let's say that I am just curious as to what the application is.

Where I do object :

Christopher Schultz wrote:
...

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.

Wrong. I am also a mod_perl hacker. In a mod_perl environment, scripts (or handlers) do
not "terminate", and memory is not recycled (this is even an inconvenient of mod_perl, and
something to watch when designing mod_perl applications).

So I am not objecting to using 3000 MB of Heap, I am just curious.
If someone like Eric Robinson can run a non-trivial multi-user Tomcat application with an
average 64 MB of Heap and you can do pretty much the same, then I am curious as to which
Tomcat application (or situation) may require 3,000 MB of Heap, which is 50 times more.

A secondary motive for my question to the OP, was to find out whether this size was really
the result of a rational calculation (or experience), or just some number plucked out of
the air.
RAM prices are fickle, but let's say that for server-quality RAM, one currently pays 25
US$ per GB.

And we do not know who the OP works for, but say he is talking about 1,000
Tomcat servers.
Saving 1 GB of Heap to run his applications would thus mean saving 25,000 US$.
I believe it is worth asking the question.

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

Re: [OT] Tomcat unexpectedly shuts down

2010-08-10 Thread Christopher Schultz

-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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

65 matches

Mail list logo