On Wed, Jul 22, 2020, 16:58 Ragavendhiran Bhiman (rabhiman) <rabhi...@cisco.com.invalid> wrote:
> Sorry Martin, > > My answers are inline. > Take a heap dump and analyze it! > Thanks & Regards, > Raghav > > On 22/07/20, 7:20 PM, "Ragavendhiran Bhiman (rabhiman)" > <rabhi...@cisco.com.INVALID> wrote: > > Hello Martin, > > Thanks for your reply > > > https://www.dropbox.com/sh/o6zra7pf2o1xpge/AAA1J7BaVdPDF7s3RjPmy0xBa?dl=0 > > Here is the link I have shared the flame graph. > Also kindly check my answers in red as well. > > Thanks & Regards, > Raghav > > > On 22/07/20, 2:33 PM, "Martin Grigorov" <mgrigo...@apache.org> wrote: > > Hi Ragavendhiran, > > On Sat, Jul 18, 2020 at 3:55 PM Ragavendhiran Bhiman (rabhiman) > <rabhi...@cisco.com.invalid> wrote: > > > Hello All, > > > > > > > > I am seeing the memory leaks from tomcat apache in the following > SSL path > > using PKCS11. Attached the flame graph of memory possible memory > leaks in > > this area. > > > > Please check the attached flame graph of the memory trace. On > simply a > > long run the memory keep on allocated in these back traces only > causing the > > memory leak, and the polling of the async profiler for more than > 6hours > > shows this clearly. Could you please help how to fix this > problem? > > > > (open this svg graph in browser only) > > > > > > > > Note: If C_DestroyObject is not called because of finalizer > accumulation > > is also tested by inducing the gc using the jmap command still > could see > > the memory never gone down after the Full GC collection as well. > Expecting > > your advice on the same. > > > > With AsyncProfiler '-e alloc' you can see what part of the code is > responsible for making most of the memory allocations, but it > doesn't tell > you whether those objects leak or not. AsyncProfiler helps you to > identify > the top allocations and if you manage to reduce them then you will > reduce > the GC runs and the time they take. > To debug memory leaks you need to take a heap dump, e.g. with 'jmap > -dump:live,format=b,file=heap.bin <PID>' and analyze it. I'd > recommend you > to use Eclipse MAT to do that. > > <Raghav> "Yes with async profiler and just leaving the server without > any sequence of action the memory started growing (RSS grows) when I > profiled during that sequence there is no other memory allocation happening > except this one. > That’s why I am suspecting this flow clearly. Samples are only through > this flow only". > > Also in your flame graph I see that Netty is responsible for > 49.04% of > the allocated objects and Tomcat for just 25.32%. > > > > > > Regards, > > > > Raghav > > > > Infrastructure engineer, > > > > Cisco ISE. > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > >
