Chris, My apologies for late response; just realized earlier this afternoon that I didn't respond.
On Thu, Apr 4, 2013 at 2:32 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Howard, > > On 4/3/13 4:15 PM, Howard W. Smith, Jr. wrote: > > On Tue, Apr 2, 2013 at 5:12 PM, Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > >> If you don't re-deploy your webapp, then daily rolling Tomcat > >> restarts are not necessary. I wonder why you are re-deploying > >> your web application so many times? > > > > As a new tomcat user and still somewhat junior java/jsf developer, > > I restart tomcat whenever I have new software changes to > > deploy-and-want-to-run-on the production server. sometimes, I > > deploy-and-restart multiple times per day, but sometimes, I'm able > > to let tomcat/tomee run for days without restart. > > That's not really conducive to high-availability. Are you using > Tomcat's parallel-deployment feature? > Agreed, and not using parallel-deployment feature at the moment. > > >> We run several Tomcats in parallel with modest heaps (less than > >> 512MiB each) and they can run for months before we stop them for > >> upgrades. It *is* possible to run JVMs without running out of > >> memory... > > > > > > I too, have not experienced any OOME, and recently, per what I > > have seen-and-read of other (more senior java developers than > > myself), I have decreased memory settings in my java options on > > tomcat7w.exe (see below). > > > > -Xmx1024m -XX:MaxPermSize=384m -XX:+UseTLAB > > -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled > > Your heap settings should be tailored to your environment and usage > scenarios. Interesting. I suppose 'your environment' means memory available, operating system, hardware. Usage scenarios? hmmm... please clarify with a brief example, thanks. :) heap settings tailored to 'my' environment and usage... hmmm, not many users hitting the app, app is not used 'all day long', app has @Schedule tasks that connects to an email acct, downloads customer email requests, and inserts customer requests into database (Martin recommended to close resources; sometime ago, I had to refactor all of that code, and I am closing the connection to the email acct, and open the connection when @Schedule tasks are executed), i am using JMS via TomEE/activeMQ to perform some tasks, asynchronously (tomee committers told me that use of @Asynchronous would be better, and less overhead); honestly, I do open 2 or 3 JMS resources/queues in @ApplicationScoped @PostConstruct (if I'm not mistaking) and close those resources in @ApplicationScoped @PreDestroy; why? I think I read on ActiveMQ site/documentation, where they recommend that that is better on performance, than open/close-on-demand. Almost forgot...as I mentioned in another thread, as enduser changes data, I have an implementation that keeps google calendar in sync with the database, which involves JMS/ActiveMQ/MDB and many/multiple requests to google calendar API. hmmm, more about usage, I have the following: <Resource id="jdbc/...." type="javax.sql.DataSource"> JdbcDriver org.apache.derby.jdbc.EmbeddedDriver JdbcUrl jdbc:derby:....;create=true UserName .... Password .... JtaManaged true jmxEnabled true InitialSize 2 MaxActive 80 MaxIdle 20 MaxWait 10000 minIdle 10 suspectTimeout 60 removeAbandoned true removeAbandonedTimeout 180 timeBetweenEvictionRunsMillis 30000 jdbcInterceptors=StatementCache(max=128) </Resource> > You can find "conventional wisdom" that recommends pretty > much any heap configuration you want. The only thing that I can > consistently recommend to anyone is to set -Xms and -Xmx to the same > value, since on a server you're pretty much guaranteed to get to -Xmx > pretty quickly, anwyay. You may as well not thrash the heap space(s) > getting there. > Interesting, I did set -Xms and -Xmx to the same value (as you and others-on-this-list have recommended, thanks). > > > My Windows 2008 R2 Server (64bit 32GB RAM) never seems to get > > higher than 1% CPU, and I think I do have memory leaks somewhere in > > the app, but FWIW (in heap dump in java visual vm), the memory > > leaks seem to be tomee leaks. In Java Visual VM, I do see the > > memory grow over time, as the app is used (without a tomcat restart > > or re-deploy of app and then restart tomcat), but I still have not > > seen OOME...'yet'. > > What does your heap usage graph look like? It should be a nice > sawtooth-looking thing, like this: > > /|/|/|/|/|/|/|/|/| > > I do occasionally see the sawtooth-looking graph, > You'll see that the small sawtooth pattern grows in basis over time > and then there is a major GC which will reset you back to some > baseline, then the process starts over again. > and eventually, I see the graph even out (non-sawtooth-looking graph). > > If you never get OOMEs, why do you think you have memory leaks? remember, I do restart tomee quite often, especially when I have software updates to deploy to/on the server. It's been a while, since I let it run a few days without stop-deploy-start. I am looking forward to letting it be and running without touching it, so I can see if it results in an OOME or reaches the peak. Or > that TomEE does? > I would rather take the blame. My first year of developing the JSF web app, I was all into xhtml pages and Java, now I am more in the Java side of things and performance performance performance, especially since I'm using tomcat (via tomee) and listening in on many topics on this tomcat user list (and learning and trying to apply this/that). I'm already spreading the word to others how helpful you all are and how I'm learning a bit more...outside of JSF world. :) > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBCAAGBQJRXcdIAAoJEBzwKT+lPKRYb70P/jI9QtV1+anIXCx04niQNDJP > BSipr2ScOQ2DJNNBjwWAth9AqbzC/nKX4fNlqKCSqWmpZf3JyFChFi/nQJajZQRR > 3EJEYLXP3YBRPfixRZLrcUw9rrVLs/+apFL4XZCdgkFvrPto201E9ef99ns7Ya+g > oBWr51g8Fkx5jeztRmzg+H/8+KVICuHUVXTCBQtuybwTfCyWKFwZs5lfmKiX7oKC > 1ts7S6mIhzpFjO+KFxnFWZkM4ch7SADqCe5WhxnOYpjaz7p7d2XGv1iamjsGVKF2 > FE1bZvOiyEFga6vlh1TpAFmAnOmHmkHtxNAG6eSLeOfYkxKAqSy4z5O6leoP/tUc > Vri2+GIxwyxyUYprTnvQW7S1UTQF6t658itnZXLrnvRr8Oj/7tzmFcScDvajbYUx > P8tECk7SENg0Sr6T8tY3VjR+A1c1u8i5k9iLDayVE8zxcDvCA6n2cVmtj/5K3xwe > MNWhsr6kfca9q7CU5fIe38ebrsw8+UU4J2TkrtHYUpc9uC1AxXmLcC8LEXCV/IiZ > pIHVlIj2VztPODHfpQvPVUH7VkQKu0M3WbeR+OTQDJJs8X7MLou+YFao+3ri0x9/ > 09i6VS+AC8E8zqQcl0KNeBJf7kuTKP/lguLcCRby0YC2YuppwHaBcRiECKy1UDZR > FB/X9VbiGKGt95lZvZae > =X3iQ > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
