[
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).
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
