[
https://issues.apache.org/jira/browse/TS-2796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995956#comment-13995956
]
Zhao Yongming commented on TS-2796:
-----------------------------------
I don't know what is this issue looking for, if we focus on the last line of
memory dump, the memory/cacheVConnection, please ignore my comment.
the most of the memory leaking in your memory dump result is
memory/ioBufAllocator size > 32K. and from what I can guess, you are using the
defualt CLFUS ram cache algorithm, which will produce this effect when the
system running a long time, and the big objects in memory is replaced by the
smaller ones, but memory used by big objects is not released to the system yet.
and that issue is already adressed in TS-1006, and result in the reclaimable
freelist memory management codes, already shiped in >4.0 releases, with a
configure options to enable.
so, if this is the cause, please help verify that your problem is still there
with reclaimable freelist enabled, and you may test the simple LRU algorithm in
the ram cache too.
thanks
> 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)
