-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joe,
On 10/6/2009 3:44 PM, Joe Hansen wrote: > I did not check the CPU usage when the issue happened. I just checked > the web application logs and found that first there was an > OutOfMemoryError, followed by MySQL errors when > TWFotoSetListDAO.getAllFotosets tried to get a database connection. It's possible that, if you really are grabbing photos (like, actual images) from a database and fitting them into memory, you might just be busting your heap yourself (rather than CAS, etc.). Are there large objects that you store in memory and/or sessions? > I am *guessing* : > I changed the session timeout to 4 hours for the Jasig CAS > Single-Signon web application. This stores a ton of tickets in memory. > During a 4 hour period when there are more http requests, the 512MB of > Java Heap space is not sufficient to store all these tickets. During > that time OutOfMemoryError happens and all hell breaks loose > subsequently. Wow, those "tickets" seem very heavyweight. Try this when the server is "quiet" and then, later, when it's getting stormed: $ jmap -histo [jvm pid] > heap.log Then, go into the heap log and see what's taking up so much of your memory. For instance, if I run this against my own JVM running in development, here are the top 10 objects in memory: Size Count Class description - ------------------------------------------------------- 10785200 98394 char[] 5548488 40283 * ConstMethodKlass 2911352 7238 byte[] 2465208 102717 java.lang.String 2259496 40283 * MethodKlass 2212736 54518 * SymbolKlass 2171032 3767 * ConstantPoolKlass 1912032 7936 int[] 1761184 38585 java.lang.Object[] 1500112 3767 * InstanceKlassKlass These are the objects taking up most memory. If you look at the "count" column, you can see how many of the objects are in memory. I suggest looking at both the "size" and the "count" columns, because your understanding of the "size" of an object and the JVM's notion may differ: most heap space is taken up by byte and char arrays and things like that, but then encapsulated into "larger" objects that, themselves, take up very little space. You may find that you have thousands of CAS tickets in memory and that they are very heavy. You may also find that the tickets themselves aren't the problem, but that a 4-hour session timeout leads to sessions with huge amounts of cached information in them. It's possible that your webapp is simply being careless with memory if you want a 4-hour session timeout. You might want to invest in a real memory profiler to see what is happening. These products can give you a better picture of "large" objects that you can look at to make decisions as to where you will apply your efforts. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrM2wYACgkQ9CaO5/Lv0PCjTwCfS/bwZmXLT+BUgYxJVyqIv6tT AuYAn1Jupcl6eB240BHH3pvtKJNGTglq =XDLj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
