On Tue, May 21, 2013 at 2:04 AM, Yunkai Zhang <yunkai...@gmail.com> wrote:
> > > > On Tue, May 21, 2013 at 1:51 AM, Leif Hedstrom (JIRA) <j...@apache.org>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. > And actually, reclaimable-freelist is based on thread-local list. > > > >> >> 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 > -- Yunkai Zhang Work at Taobao
