Thanks Olaf and Suvendu for the response. We are using 1.2 MB of heap size which is enough and haven't created an issue so far.
On Thu, Mar 30, 2017 at 9:51 AM, Suvendu Sekhar Mondal <suv3...@gmail.com> wrote: > >Memory heap dump generated is of > >Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k > > >Overview shows 580.9 MB occupied by remainder's. > > >Problem suspect:- > >465 MB occupied by remainder > > Remainder section has retained a good chunk of memory. That indicates > lots of small objects are being created by different apps. Your "Live > Set" is not very big. What is the heap size? You also mentioned, > Tomcat process was consuming high CPU. If you have small heap and all > of it is filled up by live objects then JVM will run frequent GC to > clean up some space. In that case CPU usage will be high for Tomcat > process. > > As Olaf indicated, you can try to increase heap size and see if the > problem goes away. But before that, I am curious to see what heap and > GC settings you are using. Please post that info. > > Thanks! > Suvendu > > On Thu, Mar 30, 2017 at 2:01 PM, Olaf Kock <tom...@olafkock.de> wrote: > > Am 30.03.2017 um 01:33 schrieb Utkarsh Dave: > >> Hello all, > >> > >> My tomcat (7.0.72) hosts several web aplications in the server (based in > >> linux 6.8). > > [...] > >> Memory heap dump generated is of > >> Size: 787.3 MB Classes: 139k Objects: 19.3m Class Loader: 1.6k > > The combination of "hosts several web applications" and a heap space of > > this size does not convince me of a leak - it might be the memory > > requirement of one of the webapps. A leak is typically something that > > grows uncontrolled until you run out of heapspace, no matter how much > > you grow the available space. > >> In the thread dumps I see these threads repeatedly. I wonder these > pointing > >> to com.rsa.sslj.x. > > You seem to be handling https requests from Tomcat. If you're not happy > > with the implementation of this endpoint/protocol you should move this > > to an Apache httpd or similar and just forward to tomcat, so that tomcat > > does not deal with encryption. > > > > As a conclusion: Your problem might not be poorly designed clients, it > > might be poorly equipped servers - I'd try to double the memory > > allocated to Tomcat's heap and potentially tune the garbage collector. > > If you run into problems, you might also identify one of the > > webapplications that eats up your resources (no matter what the clients > > do). > > > > Olaf > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
