[ 
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13997221#comment-13997221
 ] 

Zhao Yongming commented on TS-2796:
-----------------------------------

yeah, I know you may think that the reclaim freelist is hard to manage and evil 
in coding, but if we can confirm it may help in this case, I'd like you think 
of enable it by default, we really should not waste so many time here, and pull 
back some not so experiencd users when they may think that we do have big 
memory problem in core.

I'd push on the other enhancement you like to make it enable by default. :D

> Leaking CacheVConnections
> -------------------------
>
>                 Key: TS-2796
>                 URL: https://issues.apache.org/jira/browse/TS-2796
>             Project: Traffic Server
>          Issue Type: Bug
>          Components: Cache
>    Affects Versions: 4.0.2, 4.2.1, 5.0.0
>            Reporter: Brian Geffon
>              Labels: yahoo
>             Fix For: 5.0.0
>
>
> It appears there is a memory leak in 4.0.x, 4.2.x, and master leaking 
> CacheVConnections resulting in IOBufAllocator leaking also, here is an 
> example:
>      allocated      |        in-use      | type size  |   free list name
>            67108864 |                  0 |    2097152 | 
> memory/ioBufAllocator[14]
>            67108864 |           19922944 |    1048576 | 
> memory/ioBufAllocator[13]
>          4798283776 |           14155776 |     524288 | 
> memory/ioBufAllocator[12]
>          7281311744 |           98304000 |     262144 | 
> memory/ioBufAllocator[11]
>          1115684864 |          148242432 |     131072 | 
> memory/ioBufAllocator[10]
>          4974444544 |          379977728 |      65536 | 
> memory/ioBufAllocator[9]
>          9902751744 |         5223546880 |      32768 | 
> memory/ioBufAllocator[8]
>         14762901504 |        14762311680 |      16384 | 
> memory/ioBufAllocator[7]
>          6558056448 |         6557859840 |       8192 | 
> memory/ioBufAllocator[6]
>            41418752 |           30502912 |       4096 | 
> memory/ioBufAllocator[5]
>              524288 |                  0 |       2048 | 
> memory/ioBufAllocator[4]
>                   0 |                  0 |       1024 | 
> memory/ioBufAllocator[3]
>                   0 |                  0 |        512 | 
> memory/ioBufAllocator[2]
>               32768 |                  0 |        256 | 
> memory/ioBufAllocator[1]
>                   0 |                  0 |        128 | 
> memory/ioBufAllocator[0]
>             2138112 |            2124192 |        928 | 
> memory/cacheVConnection
> [~bcall] has observed this issue on 4.0.x, and we have observed this on 4.2.x.
> The code path in CacheVC that is allocating the IoBuffers is 
> memory/IOBuffer/Cache.cc:2603; however, that's just the observable symptom 
> the real issue here is the leaking CacheVC.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to