The Fast allocators mechanism is implemented by ProxyAllocator.

There are 2 config options in record.config:

proxy.config.allocator.thread_freelist_size (I_ProxyAllocator.h:extern int
thread_freelist_high_watermark;)
proxy.config.allocator.thread_freelist_low_watermark
(I_ProxyAllocator.h:extern int thread_freelist_low_watermark;)

according to the code in I_ProxyAllocator.h:

126 #define THREAD_FREE(_p, _a, _t)                            \
127   do {                                                     \
128     *(char **)_p = (char *)_t->_a.freelist;                \
129     _t->_a.freelist = _p;                                  \
130     _t->_a.allocated++;                                    \
131     if (_t->_a.allocated > thread_freelist_high_watermark) \
132       thread_freeup(::_a, _t->_a);                         \
133   } while (0)

One EThread can not keeps more than thread_freelist_high_watermark number
of object in Fast Allocators.

And keeps at least thread_freelist_low_watermark number of object in Fast
Allocators.

 97 template <class C>
 98 inline void
 99 thread_freeup(ClassAllocator<C> &a, ProxyAllocator &l)
100 {
101   C *head = (C *)l.freelist;
102   C *tail = (C *)l.freelist;
103   size_t count = 0;
104   while (l.freelist && l.allocated > thread_freelist_low_watermark) {
105     tail = (C *)l.freelist;
106     l.freelist = *(C **)l.freelist;
107     --(l.allocated);
108     ++count;
109   }
110
111   if (unlikely(count == 1)) {
112     a.free(tail);
113   } else if (count > 0) {
114     a.free_bulk(head, tail, count);
115   }
116
117   ink_assert(l.allocated >= thread_freelist_low_watermark);
118 }


With these 2 options, you can reduce the memory used by Fast Allocators.
You should be aware of keeping thread_freelist_low_watermark less than
thread_freelist_high_waterma

2016-12-20 4:19 GMT+08:00 Vamsi Ambati <[email protected]>:

> DevOps is  complaining about the excessive memory usage of ATS 7.0, in
> this process just noticed a comment in one of the source file(Allocator.h)
>
> " @note Fast allocators could accumulate a lot of objects in the
>  free pool as a result of bursty demand. Memory used by the objects
>  in the free pool never gets freed even if the freelist grows very
>  large.”
>
> My question is, if the above comment is right  ,are there any caps/limits
> to control the growth of this free list ?? If so, Could some one Please
> share ?
> We are running ATS 7.0  on VMs with 4GB/8GB RAM  and ram cache is
> configured to 48MB .
>
>
>  Vamsi

Reply via email to