Hi Chris, Here is link for Dump files,
https://drive.google.com/folderview?id=0BxOQjvXCnkSifjZEcEYzUTNTbUFoUWdrdmMyT18wdkZDS0hEOEgwRnl6RTBWN0V6UlA1YU0&usp=sharing I tried using eclipse MAT Analyser and I see most of the threads on related to tomcat web context loader. I still need to spend some time on that. I think my apps still needs some cleanup. After a day or 2 , it often dies a slow death with message, Exception in thread "ajp-bio-17703-exec-11" Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "ajp-bio-17703-exec-11" I am going to upload a new war today and see if it resolves the issue. I will need some help with from this group in managing bots which are spanning 100's of sessions in my case.I will initiate a new thread on that. Sorry for delayed replies from my end. - Kiran On Mon, Jul 6, 2015 at 4:38 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Kiran, > > On 7/5/15 10:24 AM, Kiran Badi wrote: > > Sorry for taking time to reply Chris. > > > >> Christopher Schultz wrote: Are you periodically hot-re-deploying > >> your application in production? If so, you may want to stop doing > >> that, as it appears that you have a ClassLoader-pinning leak in > >> your application or some dependent library > > > > I do not do hot deployment in production. But somehow I feel its > > leaking memory. > > What makes you think that? > > > There are some threads which for some reasons remains hanging. > > Threads related to Tomcat, or threads that are started by your > application? > > > But I think I will focus on it later on. I do have copy of your > > presentation. I will go through it and may be post couple of > > question if I have. > > The presentation is markt's, not mine. > > >> You should be able to run a reasonable service in half a gig of > >> heap space. Just be aware that caching information in your > >> application is going to significantly increase the amount of heap > >> space required by your application in a steady-state. > > > > Yup I am aware of this limitation. I know cache is often stored in > > local heap and probably that's reason it consumes heap space. > > Well... there are many ways to cache data, but if you are caching it > in your application (and not in an out-of-process-cache like ehcache, > memcached, etc.) then by definition it's in your application's heap spac > e. > > > Currently I am checking if ehcache or jcs meets my need. Ehcache > > for some reasons fills my heap very fast.I tried storing some 100 > > json strings and retrieving them. My OOM's started once I > > integrated this library in my web inf /lib folder.After I removed > > it, frequency of OOM has substantially decreased.Probably I am not > > using it correctly somewhere. > > You may also be using in-memory caching as opposed to on-disk caching. > > > Do you know what open source caching people frequently use for java > > web apps ? > > Honestly, I would spend your time by disabling any caching and making > sure that the application doesn't leak memory *before* you add any > caching before you start introducing any kind of caching. > > >> Fetching a lot of data isn't usually a big deal. Just make sure > >> that your "fetch size" is set to something reasonable. There are > >> some JDBC drivers (MySQL Connector/J in particular) that will > >> load the entire ResultSet into memory before allowing you to > >> traverse it unless you make arrangements to limit that memory > >> usage. > >> > >> But bringing-back thousands of records from a db isn't a problem > >> -- unless you don't *have to* in which case you might want to > >> optimize your queries to avoid pulling data you don't actually > >> need. > >> > >> But too-many-records would be a performance problem, not a > >> memory problem. > > > > haha.Its fetch size which my autocomplete was missing...I am not > > sure how I missed it but it was missing. > > I would remove all the caching and make sure that the application > works properly without leaking any memory before moving on to improve > performance. > > To do otherwise would be considered premature optimization. Nobody > likes an application that falls-over, even if it does so with > high-performance. Users will tolerate a slow application if it's the > only thing wrong with it. > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVmuc6AAoJEBzwKT+lPKRYBHEP/2qtLy1IuPM5JKsMregtLaBX > L9Hhg5YbazVzO2V7sajZJuCtYkDSOLkz6rI3Q7YgV+o3Pgl9YvPAyTmH2YGp59Ho > CzwP7rhkN0tx6QFBU3rpxj2Xcr6FZMzZrINg6+vi8/FBFbN93kjW8tBd5OjqZSi8 > hd5P4pvkKEWM2UHkCtdqWDLACi2oldLYNHeaVcVNUCcbYJodCek9OEIHK5OeRV27 > VrhTngQvcRu7LivbjPp2yl4w4APDuctSX3YkVyHmCbNFdE2WzogKbWOfaG2ylIbx > F/wvBIgLocVIaOL2G2TJkvRYS7oxK7Fsh4JtCdMPZs0Wpkznz+BkBQy4aCy2oWQ2 > FBB9dPxrs0o+8RXKPP7wre8MutcZ2bOgieFdSq9JRe0NrEmhvaVgYKQNT+lVjMmC > 8+m1W8/Z1z3Rhkc0lnH0U+S2KoPN/FToEIMKNZgrkg/EoAotBYxp8kV06d5+DvP1 > cXqp/Q5HDjZTt9+elaMOvmYzFIZR9TLu8U7uH3tnaKtqtPGzqP7TOJd9mwzqescW > Be71awY/r+WQiWga6yLHPKD8hrTKjmZjaewm7WOwxNrVcjdi/IN8YUR6j6/Gq8dh > 4tYj4UoJLNq5yTA3jywfHRjb+L20B8Mr7aT2vMaGWFo1nCwNAotYulfEjJ5UVVit > k+fS5XpaNzXtt/yM+a8b > =ftJv > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
