-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A C,
A C wrote: > We've been experiencing horrendous OOMEs recently after deploying 40 clones > of a vendor's .war file which encompasses their application/portal. The > context is about 100MB Lesee... 100 MB times 40 instances .. mm... carry the 7 ... hey, that's 4GB! Where have I heard that number before... hmm.. something about ... right! The maximum process memory on a 32-bit OS! Nevermind the fact that a 32-bit JVM can't allocate that much memory in one huge chunk. It looks like your requirements are outstripping your capabilities. If you want to run all these instances on the same machine, you're going to need a 64-bit OS. > When we deploy just ONE of these contexts onto our tomcat server, > eveything's "fine". Probably because it uses 1/40 of the memory that 40 of them require. > When we have 30, we need a daily restart, even though we never get more than > 25 sessions to the database in that time … You should look at what is taking up so much memory. > My question is, does placing the jtds.jar in /server/lib cause an issue? Almost certainly not. It's probably not doing you any good, either, since your application can't use it (only the server can, but maybe you have Tomcat managing your connection pool or something). > We're running a verbose:gc as well and have optimized to the best of our > ability xmx xms settings Like what? An example would be enlightening. > [I] now question some of our deployment mechanics. I'm pretty sure that you just need more memory than you have. If you're right, and each instance of this app takes ~100MB, then you simply cannot deploy 40 of them on a single 32-bit machine. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHDSSV9CaO5/Lv0PARAtljAKCX1LhV8nl+cxnc5pSfRh6NAqNDLQCgkxDU xbMHY6ha/JLZcPRCDB7K5RE= =GBVj -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
