[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996658#comment-13996658
]
Brian Geffon commented on TS-2796:
----------------------------------
I do not believe that is the issue. Firstly, reclaimable freelist cannot solve
our issue because (from the memory output) the freelist items are currently in
use and there is nothing that can be recalimed. Also, I've tracked down the
source of the IOBufferBlock allocations and they are coming from Cache.cc:2603
which is:
buf = new_IOBufferData(iobuffer_size_to_index(io.aiocb.aio_nbytes,
MAX_BUFFER_SIZE_INDEX), MEMALIGNED);
I believe this issue is a valid leak as these buffers are not being returned to
the freelist properly.
> 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)
