-----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
