Memcached comprehensive analysis-2. Understanding memcached memory storage

Series of articles: complete memcached analysis-1. basic memcached analysis-2. understanding memcached's memory storage memcached comprehensive analysis-3. memcached's deletion mechanism and development direction: Comprehensive Analysis of memcached-4. comprehensive Analysis of memcached distributed algorithm-5. memcached applications and compatibility

Series of articles: complete memcached analysis-1. basic memcached analysis-2. understanding memcached's memory storage memcached comprehensive analysis-3. memcached's deletion mechanism and development direction: Comprehensive Analysis of memcached-4. comprehensive Analysis of memcached distributed algorithm-5. memcached applications and compatibility

Series Article Navigation:

Complete memcached analysis-1. Foundation of memcached

Memcached comprehensive analysis-2. Understanding memcached memory storage

Memcached comprehensive analysis-3. memcached deletion mechanism and development direction

Comprehensive Analysis of memcached-4. Distributed memcached Algorithms

Memcached comprehensive analysis-5. memcached applications and compatible programs

The second part of memcached comprehensive analysis is as follows.

Posting date: 2008/7/9
Author: Toru Maesaka)
Http://gihyo.jp/dev/feature/01/memcached/0002

I am the precognition OF THE mixi Research and Development Group. The last article introduced that memcached is a distributed high-speed cache server. This section describes the implementation of the internal structure of memcached and the memory management mode. In addition, the vulnerabilities caused by the internal structure of memcached will also be described.

Slab Allocation mechanism: sort out the memory for Reuse

By default, the latest memcached uses the Slab Allocator mechanism to allocate and manage memory. Before the emergence of this mechanism, the memory is allocated by simply malloc and free all records. However, this method will cause memory fragmentation and increase the burden on the memory manager of the operating system. In the worst case, the operating system will be slower than the memcached process itself. Slab Allocator was born to solve this problem.

Next let's take a look at the Slab Allocator principle. Below are the objectives of slab allocator in the memcached document:

The primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixed-size memory chunks coming from a few predetermined size classes.

That is to say, the basic principle of Slab Allocator is to divide the allocated memory into blocks of a specific length according to the predefined size to completely solve the memory fragmentation problem.

The principle of Slab Allocation is quite simple. Divide the allocated memory into chunk blocks of various sizes, and divide the chunk blocks into groups )().

Structure of Slab Allocation

In addition, slab allocator can reuse allocated memory. That is to say, the allocated memory is not released, but reused.

Slab Allocation terminology

Page

Memory space allocated to Slab. The default value is 1 MB. After being allocated to Slab, it is split into chunks based on the size of slab.

Chunk

Memory space used to cache records.

Slab Class

A chunk group of a specific size.

Principle of caching records in Slab

The following describes how memcached selects slab for the data sent by the client and caches it to chunk.

Memcached selects the slab () that best fits the data size according to the size of the received data (). Memcached stores the list of idle chunks in slab. Select chunks based on the list and then cache the data.

Method for Selecting a group for storing records

In fact, Slab Allocator also has advantages and disadvantages. The following describes its shortcomings.

Disadvantages of Slab Allocator

Slab Allocator solves the original memory fragmentation problem, but the new mechanism also brings new problems to memcached.

This problem occurs because the allocated memory is of a specific length, so the allocated memory cannot be effectively used. For example, if 100 bytes of data are cached to 128 bytes of chunk, the remaining 28 bytes will be wasted ().

Use of chunk Space

There is no perfect solution for this problem, but the document records a more effective solution.

The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that's at all possible) common sizes of objects that the clients of this particle installation of memcached are likely to store.

That is to say, if you know the public size of the data sent by the client in advance, or only cache the data of the same size, you only need to use a list of groups suitable for the data size to reduce waste.

However, it is a pity that no optimization can be performed now. We can only look forward to future versions. However, we can adjust the differences in slab class size. The following describes the growth factor option.

Use Growth Factor FOR Tuning

Memcached specifies the Growth Factor (through the-f option) at startup to control the differences between slab to some extent. The default value is 1.25. However, before this option appeared, this factor was fixed to 2, called the "powers of 2" policy.

Let's start memcached in verbose mode with the previous settings:

$ memcached -f 2 -vv

The following figure shows the verbose output after startup:

slab class   1: chunk size    128 perslab  8192slab class   2: chunk size    256 perslab  4096slab class   3: chunk size    512 perslab  2048slab class   4: chunk size   1024 perslab  1024slab class   5: chunk size   2048 perslab   512slab class   6: chunk size   4096 perslab   256slab class   7: chunk size   8192 perslab   128slab class   8: chunk size  16384 perslab    64slab class   9: chunk size  32768 perslab    32slab class  10: chunk size  65536 perslab    16slab class  11: chunk size 131072 perslab     8slab class  12: chunk size 262144 perslab     4slab class  13: chunk size 524288 perslab     2

It can be seen that, starting from the 128-byte group, the size of the group increases to 2 times that of the original group. The problem with this setting is that the slab is quite different and sometimes it is quite a waste of memory. Therefore, to minimize memory waste, the growth factor option was added two years ago.

Let's take a look at the output of the current default settings (f = 1.25) (limited space, only 10th groups are written here ):

slab class   1: chunk size     88 perslab 11915slab class   2: chunk size    112 perslab  9362slab class   3: chunk size    144 perslab  7281slab class   4: chunk size    184 perslab  5698slab class   5: chunk size    232 perslab  4519slab class   6: chunk size    296 perslab  3542slab class   7: chunk size    376 perslab  2788slab class   8: chunk size    472 perslab  2221slab class   9: chunk size    592 perslab  1771slab class  10: chunk size    744 perslab  1409

It can be seen that the gap between groups is much smaller than the factor of 2, and it is more suitable for caching hundreds of bytes of records. From the above output, some calculation errors may be found. These errors are intentionally set to keep the number of bytes aligned.

When you introduce memcached into a product or directly use the default value for deployment, it is best to recalculate the expected average length of data and adjust the growth factor for the most appropriate settings. Memory is a precious resource, which is a waste of resources.

Next we will introduce how to use the memcached stats command to view various information such as slabs utilization.

View the internal status of memcached

Memcached has a command named stats, which can be used to obtain various information. There are many ways to execute commands. telnet is the simplest:

$ Telnet host name port number

After connecting to memcached, enter stats and press enter to obtain information including resource utilization. In addition, enter "stats slabs" or "stats items" to obtain information about cache records. Enter quit to end the program.

For more information, see protocol.txt in the memcachedsoftware package.

$ telnet localhost 11211Trying ::1...Connected to localhost.Escape character is '^]'.statsSTAT pid 481STAT uptime 16574STAT time 1213687612STAT version 1.2.5STAT pointer_size 32STAT rusage_user 0.102297STAT rusage_system 0.214317STAT curr_items 0STAT total_items 0STAT bytes 0STAT curr_connections 6STAT total_connections 8STAT connection_structures 7STAT cmd_get 0STAT cmd_set 0STAT get_hits 0STAT get_misses 0STAT evictions 0STAT bytes_read 20STAT bytes_written 465STAT limit_maxbytes 67108864STAT threads 4ENDquit

In addition, if the libmemcached client library for C/C ++ is installed, the memstat command is installed. It is easy to use. You can use fewer steps to obtain the same information as telnet and obtain information from multiple servers at a time.

$ memstat --servers=server1,server2,server3,...

Libmemcached can be obtained from the following address:

• Http://tangent.org/552/libmemcached.html

View slabs usage

Using memcached to create a Perl script written by Brad named memcached-tool, you can easily get the usage of slab (it organizes the returned values of memcached into easy-to-read formats ). You can obtain the script from the following address:

• Http://code.sixapart.com/svn/memcached/trunk/server/scripts/memcached-tool

The usage is extremely simple:

$ Memcached-tool Host Name: port option

You do not need to specify an option to view slabs usage. Use the following command:

$ Memcached-tool Host Name: Port

The obtained information is as follows:

 #  Item_Size   Max_age  1MB_pages Count   Full? 1     104 B  1394292 s    1215 12249628    yes 2     136 B  1456795 s      52  400919     yes 3     176 B  1339587 s      33  196567     yes 4     224 B  1360926 s     109  510221     yes 5     280 B  1570071 s      49  183452     yes 6     352 B  1592051 s      77  229197     yes 7     440 B  1517732 s      66  157183     yes 8     552 B  1460821 s      62  117697     yes 9     696 B  1521917 s     143  215308     yes10     872 B  1695035 s     205  246162     yes11     1.1 kB 1681650 s     233  221968     yes12     1.3 kB 1603363 s     241  183621     yes13     1.7 kB 1634218 s      94   57197     yes14     2.1 kB 1695038 s      75   36488     yes15     2.6 kB 1747075 s      65   25203     yes16     3.3 kB 1760661 s      78   24167     yes

The meaning of each column is:

Column	Description
#	Slab class no.
Item_Size	Chunk Size
Max_age	Survival time of the oldest record in LRU
1MB_pages	Number of pages allocated to Slab
Count	Number of records in Slab
Full?	Whether the Slab contains idle chunk

The information obtained from this script is very convenient for tuning and is strongly recommended.

Memory storage Summary

This section briefly describes the cache mechanism and Optimization Method of memcached. I hope you can understand the memory management principles and advantages and disadvantages of memcached.

Next time, we will continue to explain the principles of LRU and Expire, as well as the latest development direction of memcached, the Extensible System (pluggable architecher )).