Re: [OT] Tomcat unexpectedly shuts down
-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
Re: [OT] Tomcat unexpectedly shuts down
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
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
-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-unsubscr...@tomcat.apache.org
For
RE: [OT] Tomcat unexpectedly shuts down
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
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
