Our experience at Oath is that 7.1.2 is much improved. On Tue, Mar 27, 2018 at 1:13 PM, Chou, Peter <pbc...@labs.att.com> wrote:
> Thanks for the responses. We will probably wait until we move to the next > release of ATS (7.1.x) to re-evaluate this to see if there is any > improvement. > > -----Original Message----- > From: Alan Carroll [mailto:solidwallofc...@oath.com.INVALID] > Sent: Monday, March 19, 2018 2:53 PM > To: dev@trafficserver.apache.org > Subject: Re: ATS Memory Leak? > > Fei (duke8253) found a number of leaks doing the jemalloc work for 8.0. I > wouldn't expect any of those fixes to get back ported to 6.x. You might > search his PRs to see them. > > On Thu, Mar 15, 2018 at 7:51 PM, Shu Kit Chan <chanshu...@gmail.com> > wrote: > > > I tried some memory leak debugging with jemalloc before. > > > > The experience is mentioned here - > > https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki. > apache.org_confluence_display_TS_&d=DwIBaQ&c=LFYZ-o9_ > HUMeMTSQicvjIg&r=8c5kS62dKm3-obVyLvkwkc-kTTgV1vAsbxSPwL- > yi3o&m=Ev5upk0aWRmQYvwhbK-KWGqA6Fz3kFJE3ZEZMVvzDDo&s=1eayWyMoU- > xaIuSroHrzio06A76Gv1apgRS0OjrTlKQ&e= > > Presentations+-+2017?preview=/70255385/74684709/ATSSummit_jemalloc.pptx > > > > Perhaps we can then see what components of the code is contributing to > > the memory buildup. > > > > Thanks. > > > > Kit > > > > On Thu, Mar 15, 2018 at 3:57 PM, Chou, Peter <pbc...@labs.att.com> > wrote: > > > Hi All, > > > > > > We have been experiencing a slow memory leak with ATS 6.2.1 which > > requires a process restart (before memory exhaust) on the order of weeks. > > We have tried to gather information with a debug build (compiled with > > --enable-debug and --with-tcmalloc-lib), but the process seems to be > > unstable and crash after a couple of days with these build options. Since > > the heap-check seems to output only on normal program exit, we have > > manually stopped the process after a couple of days with the following > > results -- > > > > > > (pprof) top50 > > > Total: 737811 objects > > > 737376 99.9% 99.9% 737376 99.9% ats_malloc > > /usr/src/git/trafficserver/lib/ts/ink_memory.cc:59 > > > 334 0.0% 100.0% 667 0.1% BaseLogFile::open_file > > /usr/src/git/trafficserver/lib/ts/BaseLogFile.cc:326 > > > 59 0.0% 100.0% 59 0.0% ClusterVConnectionCache::init > > /usr/src/git/trafficserver/iocore/cluster/ClusterCache.cc:225 > > > 41 0.0% 100.0% 41 0.0% ats_memalign > > /usr/src/git/trafficserver/lib/ts/ink_memory.cc:105 > > > 1 0.0% 100.0% 2 0.0% BaseLogFile::open_file > > /usr/src/git/trafficserver/lib/ts/BaseLogFile.cc:320 > > > 0 0.0% 100.0% 728003 98.7% AIOCallbackInternal::io_ > complete > > /usr/src/git/trafficserver/iocore/cache/../../iocore/aio/P_AIO.h:117 > > > ... > > > 0 0.0% 100.0% 737024 99.9% CacheVC::handleReadDone > > /usr/src/git/trafficserver/iocore/cache/Cache.cc:2403 > > > ... > > > 0 0.0% 100.0% 737803 100.0% Continuation::handleEvent > > /usr/src/git/trafficserver/proxy/../iocore/eventsystem/I_ > > Continuation.h:153 > > > ... > > > > > > -- So does this look like a possible memory leak signature (with the > > cache-related AIO)? Appreciate any recommendations and insights for this > > issue. > > > > > > Thanks, > > > Peter > > >
