Still playing with slabs allocation, I found another strange result. Storing only one small value in memcached, I end up with this output for stats slabs:
STAT 1:chunk_size 104 STAT 1:chunks_per_page 10082 STAT 1:total_pages 1 STAT 1:total_chunks 10082 STAT 1:used_chunks 10082 STAT 1:free_chunks 0 STAT 1:free_chunks_end 10081 STAT active_slabs 1 STAT total_malloced 1048528 It is strange that whereas I store only one value, used_chunks report 10082. However, after deleting the value, free_chunks increase to 1, and used_chunks decrease to 10081. Why are chunks in free_chunks_end also considered as used_chunks ? On Mar 17, 12:34 pm, "[email protected]" <[email protected]> wrote: > Hello, > > I had a look at slab allocation, and saw two strange things: > > The first one concern the special value for chunk minimal size when > chunk_factor is 2: > /* Factor of 2.0 means use the default memcached behavior */ > if (factor == 2.0 && size < 128) > size = 128; > > I think I understand the purpose of this one: having a chunk size > aligned on power of 2. But why am I forced to do so ? As I can tune > chunk_size with -n option, why having -f 2 -n x with x being less than > 72 (128 - sizeof(item)) isn't authorized ? > > The other point is that slab classes stop at POWER_BLOCK / 2: > while (++i < POWER_LARGEST && size <= POWER_BLOCK / 2) { > > It means some slab classes are missing whereas they may be useful. > Imagine I have the default settings. Classes grow with factor 1.25 > until class 38 (478568 bytes) and then class 39 is 1MB. So each time I > store an item of size around half a MB, it uses a 1 MB chunk. Is it on > purpose, or is it some code that remains from time where chunk factor > was not tunable ? > > Regards, > Colin
