Analysis of memcached memory management mechanism

Memached is a high performance distributed memory object system that reduces the number of data reads to the disk and improves service speed by storing data objects in memory.

Start with the business requirements. After we insert a key-value pair (Key,value) into memcached with a single command (such as set), we need to:

1, the efficient index of the key value data;

(memcached the key value data through the hash table to manage, the concrete implementation uses the link method to deal with the hash conflict problem.) )

2, the system may frequently create new data and delete old data, need efficient memory management;

(The simplest idea is to have the new data on malloc memory, save the new data in this newly allocated memory, and leave the memory free when the data is to be deleted.) However, frequent malloc and free will result in a system memory fragmentation problem that can add to the burden of system memory management. At the same time malloc and free as system calls, there is a certain overhead in terms of timing. The solution for memcached is to create a memory pool to manage memory allocations, and the idea is to use slab allocator as the memory allocator. ）

3, the system should be able to delete the long-term unused cache data.

(memcached gives each data record an expiration time and organizes all the data of the same slab class through the LRU algorithm, deleting old data that is timed out by examining the LRU linked list when new data is inserted.) ）

Data

Item: The actual storage structure for the key value data. Item consists mainly of two parts:

The first part is the public property part, including the pointer to other item (Next,prev,h_next), the last access time, the time of Expiration (exptime), etc., the structure length is fixed;

The second part is the data part of item, which consists of CAS, key, suffix, value, because the actual key value data length is indeterminate, so the structure length of this part is not fixed.

Chunk: Divided evenly by the application of contiguous blocks of memory, such as the application of 1M contiguous memory block, can be cut into 11 88bytes of Chunk memory small block. Chunk is the memory space that is actually allocated to the item, Memcached maintains multiple chunk memory blocks of different sizes, and if an item requires 100bytes of memory space, The system will take out a chunk that is closest and larger than 100bytes to allocate the item as memory space.

For example: The Item Public Properties section requires 48bytes of memory space, the data part requires 52bytes of memory space, the item needs 100bytes contiguous memory space altogether. The memcached maintains the 184 block groups of 88bytes, Bytes, 144 bytes and bytes chunk respectively. The maximum memory size that is closest to and greater than the item requires is a chunk block with size 112bytes. So we take out an unused chunk block of the bytes, and save the data in that item to the chunk memory space. At this point, the chunk will have 12bytes of remaining memory to be temporarily wasted as fragments.

Slab Class: Manages a collection of chunk of a specific size. Memcached one contiguous block of memory allocated per default is 1M in size, and they are cut into chunk of different sizes. However, the demand of different chunk is different, in some cases, some size chunk only need a contiguous block of memory to meet business needs, but some of the size of chunk demand is larger, need to allocate more contiguous memory block to be segmented. These are divided into the same size of the chunk block group, are managed by the corresponding slab class.

memcached specifies a minimum chunk size, and a growth factor is set. The system creates slab class that manages the chunk size that grows with growth factor and maintains byte alignment. For example, with a minimum chunk size of 88bytes and a growth factor of 1.25, the system will create a slab class that manages chunk of 88bytes size, 112bytes size, 144bytes size, respectively.

typedefstruct{unsignedintSize//the chunk size of the SlabclassUnsignedintPerslab;//indicates how many chunk each slab can be cut into, and if slab is 1M, then Perslab = 1m/size    void*slots;//the item linked list to be recycledUnsignedintSl_curr;//How many recycled idle chunk are in the current listUnsignedintslabs;//How many chunk are assigned to this class?    void**slab_list;//The list array is used to maintain chunk.UnsignedintList_size;/*size of prev array*/unsignedintKilling;/*index+1 of Dying slab, or zero if none*/size_t requested;/*The number of requested bytes*/} slabclass_t;

Memory initialization
There are two types of memory initialization in memcached, namely, pre-allocation and on-demand mode. Memcached is on demand by default.

Pre-allocation, memcached will request 64M of contiguous memory (configurable) at startup by malloc, then memcached create slab class to manage different chunk sizes based on initial chunk size and growth factor, each slab Class sequentially obtains 1 1M contiguous blocks of memory from the previously requested 64M memory and divides the memory block into a corresponding size chunk block and manages it until the requested memory is exhausted.

When there is actual data to be stored in the slab under the chunk, memcached first will determine whether the slab has an expired item to be recycled, if not to determine whether there is idle chunk, if not, will give the slab to allocate 1M of contiguous memory. Slab will then slice and chunk the contiguous memory and take out an idle chunk to store the data.

On an on-demand basis, the initialization phase memcached only specifies the corresponding chunk size for each slab and does not allocate actual memory to slab.

Slab Memory Expansion

In pre-allocation initialization, we assign a block of contiguous memory of approximately 1M to the slab class of size 88bytes, and cut it into 11,915 chunk. But in practice, 11,915 Chunk are probably not enough to use. If the original chunk is all used, then new data will need 88bytes of chunk memory space. At this point memcached will expand the slab operation.

A slab_list array with an initial size of 16 exists in slab for managing contiguous blocks of memory. The first contiguous block of memory that is pre-allocated is mounted on slab_list[0]. When chunk is not enough in the first contiguous block of memory, Memcached will again assign the slab a contiguous block of memory of approximately 1M, and mount it on Slab_list[1], and also cut the contiguous memory into 11,915 chunk. and add these new chunk to the slab's idle doubly linked list. At this time the slab altogether manages 11915*2 chunk, of which the newly assigned 11,915 chunk are idle chunk.

Because the initial size of the slab_list array is 16, theoretically the slab can mount 16 such contiguous memory, and each continuous content can be divided into 11,915 chunk, that is, slab can manage 16*11915=190640 chunk. If 190,640 chunk can not meet the slab chunk demand, then memcached will be slab_list through the expansion of realloc, the size of each expansion is twice times the size of the original slab_list. Once the slab_list is expanded, the array size is 32 and the 32*11915 chunk can be allocated. As long as the system has enough memory, each slab class can manage countless chunk of the same size through slab_list expansion and allocation of new contiguous blocks of memory.

Hash Table Implementation

Memcached's hash table is implemented by linking method. Hashtable is divided into buckets, each item is determined by the hash function to determine the specific bucket, and then linked to the bucket, if there is already a linked item in the bucket (that is, there is a hash conflict), then the item through the H_ The next pointer forms the one-way list linked under the bucket. In the diagram, item A and item B are hashed into bucket[1], and they are organized as a one-way linked list by H_next and bucket[1] as the list header of the list.

LRU Linked List

An LRU list is maintained in each slab to organize the item blocks that have been allocated in the slab to record "least recently used" item information. Where heads points to the head node of the list, tails points to the tail node of the linked list. Whenever a new chunk is used, the chunk item is added to the LRU link header. Or the original used item is modified, and it is moved from the linked list to the LRU link header. Through this mechanism, the item of the link header section is guaranteed to be newly created or newly modified data, and the end item of the chain is the longest stored data in the slab.

Memcached uses the lazy removal mechanism, the system does not actively monitor the item in the data is not expired, but in the case of get to see the time stamp of the item, if it has expired to delete and release the chunk to the free list. At the same time, in the new data insert, memcached will also be the first to determine whether the slab of the end of the LRU list of the item node timeout, if the time-out, memcached will also first delete and use the time-out of the item's chunk as the new data storage space.

When the slab's LRU tail item node does not time out, but there is no chunk available in the slab and cannot be expanded from the system to a new memory space, memcached will remove the last item in the LRU list and forcibly delete and allocate its space to the new data record. Memcached can be configured to prohibit the use of the LRU mechanism, which will return an error if the chunk is exhausted in the slab and no new memory is allocated.

Data storage Process

Hash lookup for the existence of the same key value-"Select Slab class-based on item size" Assign item-from expired Item or free list to add the LRU list and hash table

Data removal process

Get the key value data through a Hashtable item-removes the item node from the hash table-"Move the item node from the LRU list-" empties the item data and adds the chunk back to the idle chunk list

Analysis of memcached memory management mechanism