On Tue, May 21, 2013 at 1:51 AM, Leif Hedstrom (JIRA) <[email protected]>wrote:
> > [ > https://issues.apache.org/jira/browse/TS-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13662206#comment-13662206] > > Leif Hedstrom commented on TS-1684: > ----------------------------------- > > Lets land this, perhaps with a configure option for now? There might be > some unforeseen downsides to this much proxy allocation (i.e. bigger memory > foot prints). > Yes, I hope this feature could enable/disable by an option. Now, reclaimable-freelist are satisfy for us with good speed and controlled usage of memory. But too much proxy allocation may lead to the old problem again. > > Also, did you change the setup to allow more than the 512 objects that > each proxy allocator is allowed to retain? I see two possible ways to > change this: > > 1) Add a new config option (records.config) to allow it to be more (or > less) than 512, with a value of '0' meaning no limits. > > 2) Somehow combine the reclaimable freelist code with the proxy > allocators, which combined with a high (or '0') setting above can be used > to reclaim objects from the freelist. > > I haven't checked the patches above, but I think #1 above is a good > requirement to control this in some way (and continue to let it fall back > to the global allocators as necessary). > > > Exciting results indeed, a huge step towards NUMA awareness! > > > Reduce the usage of global allocation/free lists - switch to using local > thread allocation/free lists > > > ----------------------------------------------------------------------------------------------------- > > > > Key: TS-1684 > > URL: https://issues.apache.org/jira/browse/TS-1684 > > Project: Traffic Server > > Issue Type: Improvement > > Components: Core > > Reporter: Bryan Call > > Assignee: Bryan Call > > Fix For: 3.3.4 > > > > Attachments: ts-1684.patch > > > > > > When running benchmarks ink_freelist_new() normally shows up as one of > if not the number one function in the code using the most CPU. Currently > ATS uses global free lists (via ClassAllocator<>, Allocator, and > SparceClassAllocator<>) for memory allocation for some of its memory > allocation. > > Here is a list of how frequently the type of allocations are used and > the "name" given to the allocator. This is a benchmark for a small object > in cache fetched 100k times. > > 400000 ink_freelist_new: hdrHeap > > 300000 ink_freelist_new: hdrStrHeap > > 203541 ink_freelist_new: ioBlockAllocator > > 199616 proxy allocator thread_alloc: eventAllocator > > 103554 ink_freelist_new: ioDataAllocator > > 103554 ink_freelist_new: ioBufAllocator[5] > > 100100 ink_freelist_new: ioAllocator > > 100000 proxy allocator thread_alloc: hdrHeap > > 100000 proxy allocator thread_alloc: cacheVConnection > > 100000 ink_freelist_new: httpSMAllocator > > 100000 ink_freelist_new: ArenaBlock > > 18507 ink_freelist_new: mutexAllocator > > 4772 ink_freelist_new: eventAllocator > > 162 ink_freelist_new: cacheVConnection > > 102 ink_freelist_new: netVCAllocator > > 100 proxy allocator init thread_alloc: httpClientSessionAllocator > > 100 ink_freelist_new: httpClientSessionAllocator > > 1 proxy allocator thread_alloc: RamCacheCLFUSEntry > > 1 ink_freelist_new: RamCacheCLFUSEntry > > 1 ink_freelist_new: hostDBContAllocator > > -- > This message is automatically generated by JIRA. > If you think it was sent incorrectly, please contact your JIRA > administrators > For more information on JIRA, see: http://www.atlassian.com/software/jira > -- Yunkai Zhang Work at Taobao
