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

Reply via email to