Directory of this document
Slab allocation mechanism: Defragment memory for reuse
· Main terms of Slab allocation
· The principle of caching records in slab
· Disadvantages of Slab Allocator
· Tuning with growth factor
· View the internal state of the memcached
· View the usage status of slabs
· Summary of memory storage
Slab allocation mechanism: Defragment memory for reuse
The most recent memcached by default uses a mechanism called slab allocator to allocate and manage memory. Prior to the advent of this mechanism, the allocation of memory was performed simply by malloc and free for all records. However, this approach can lead to memory fragmentation, aggravating the burden on the operating system memory manager, and in the worst case, cause the operating system to be slower than the memcached process itself. Slab Allocator was born to solve the problem.
Let's look at the principle of slab allocator. The following is the goal of slab allocator in the memcached documentation:
Reference
The primary goal of the slabs subsystem in memcached is to eliminate memory fragmentation issues totally by using fixed-s Ize memory chunks coming from a few predetermined size classes.
In other words, the basic principle of the Slab allocator is to divide the allocated memory into blocks of a specific length in a predetermined size to completely resolve the memory fragmentation problem.
The principle of Slab allocation is quite simple. Divide the allocated memory into blocks (chunk) of various sizes and divide the same size blocks into groups (chunk collections)
Fig. 1:slab Allocation structure diagram
Also, slab allocator has the purpose of reusing allocated memory. In other words, the allocated memory is not freed, but reused.
Main terms of Slab allocation
Page: The memory space allocated to slab, which is 1MB by default. After assigning to slab, the slab is divided into chunk according to the size of the.
Chunk: The memory space used to cache records.
Slab Class: A group of chunk of a specific size.
The principle of caching records in slab
The following shows how memcached selects slab and caches the data sent by the client to chunk.
Memcached based on the size of the data received, select the slab that best fits the data size (Figure 2). Memcached holds a list of idle chunk within slab, selects chunk based on the list, and caches the data in it.
Figure 2: How to select a group that stores records
In fact, Slab allocator also has advantages and disadvantages. Here's a look at its drawbacks.
Disadvantages of Slab Allocator
Slab allocator solved the original memory fragmentation problem, but the new mechanism also brought new problems to memcached.
The problem is that the allocated memory cannot be effectively exploited because it allocates memory of a specific length. For example, by caching 100 bytes of data into a 128-byte chunk, the remaining 28 bytes are wasted (Figure 3).
Figure 3:chunk Use of space
There is no perfect solution for this problem, but the more effective solution is documented in the documentation.
Reference
The most efficient-on-the-waste-to-use-a list of size classes that closely matches (if that's at all Possibl e) Common sizes of objects, the clients of this particular installation of memcached is likely to store.
That is, if you know in advance the common size of the data sent by the client, or if you only cache data of the same size, you can reduce waste if you use a list of groups that fit the data size.
Unfortunately, it is not possible to perform any tuning at this time, only to look forward to future versions. However, we can adjust the difference in the size of the slab class. Next, the growth factor option is described.
Tuning with growth factor
memcached specifies the growth factor factor at startup (with the-f option) to control the difference between slab to some extent. The default value is 1.25. However, before this option occurs, this factor was once fixed to 2, called the "Powers of 2" policy.
Let's try using the previous settings to start memcached in verbose mode:
2 -VV
The following is the verbose output after startup:
Slabclass 1: Chunk Size -Perslab8192Slabclass 2: Chunk Size thePerslab4096Slabclass 3: Chunk Size +Perslab2048Slabclass 4: Chunk Size1024x768Perslab1024x768Slabclass 5: Chunk Size2048Perslab +Slabclass 6: Chunk Size4096Perslab theSlabclass 7: Chunk Size8192Perslab -Slabclass 8: Chunk Size16384Perslab -Slabclass 9: Chunk Size32768Perslab +Slabclass Ten: Chunk Size65536Perslab -Slabclass One: Chunk Size131072Perslab8Slabclass A: Chunk Size262144Perslab4Slabclass -: Chunk Size524288Perslab2
As you can see, starting with a 128-byte group, the size of the group increases to twice times the original. The problem with this setting is that the difference between slab is large, and in some cases it is quite a waste of memory. Therefore, to minimize memory waste, two years ago this option was appended with growth factor.
Take a look at the current default settings (f=1.25) when the output (space limit, this is only written to the 10th group):
Slabclass 1: Chunk Size thePerslab11915Slabclass 2: Chunk Size thePerslab9362Slabclass 3: Chunk Size144Perslab7281Slabclass 4: Chunk Size184Perslab5698Slabclass 5: Chunk Size232Perslab4519Slabclass 6: Chunk Size296Perslab3542Slabclass 7: Chunk Size376Perslab2788Slabclass 8: Chunk Size472Perslab2221Slabclass 9: Chunk Size592Perslab1771Slabclass Ten: Chunk Size744Perslab1409
As can be seen, the gap between groups is much smaller than the factor of 2 o'clock, which is more suitable for caching hundreds of-byte records. From the above output, you may find some calculation errors, which are deliberately set to keep the number of bytes aligned.
When introducing memcached into a product or deploying it directly using default values, it is best to recalculate the expected average length of the data and adjust the growth factor to get the most appropriate settings. Memory is a precious resource, and a waste of it is too bad.
Here's how to use memcached's stats command to see a wide variety of information such as slabs utilization.
View the internal state of the memcached
Memcached has a command called stats that can be used to obtain a wide variety of information. There are many ways to execute commands, with Telnet the simplest:
$ telnet Host name Port number
After connecting to memcached, enter stats and press ENTER to get a variety of information including resource utilization. Also, enter "stats slabs" or "stats items" to get information about the cache record. To end the program, enter quit.
The details of these commands can refer to the Protocol.txt documentation within the memcached package.
$ telnet localhost11211Trying::1... Connected to localhost. Escape character is '^]'. Statsstat PID481STAT Uptime16574STAT Time1213687612STAT version1.2.5STAT pointer_size +STAT Rusage_user0.102297STAT Rusage_system0.214317STAT Curr_items0STAT Total_items0STAT bytes0STAT curr_connections6STAT total_connections8STAT connection_structures7STAT Cmd_get0STAT Cmd_set0STAT get_hits0STAT get_misses0STAT Evictions0STAT Bytes_read -STAT Bytes_written465STAT limit_maxbytes67108864STAT Threads4Endquit
Additionally, if you install libmemcached, the client library for the C + + language, the MemStat command will be installed. Using the method is simple, you can get the same information as Telnet with fewer steps, and you can get information from multiple servers at once.
$ memstat--servers=server1,server2,server3,...
Libmemcached can be obtained from the following address:
Http://tangent.org/552/libmemcached.html
View the usage status of slabs
Using memcached, a Perl script named Memcached-tool, written by Brad, makes it easy to get slab usage (IT organizes memcached return values into easy-to-read formats). You can get the script from the following address:
Http://code.sixapart.com/svn/memcached/trunk/server/scripts/memcached-tool
The method of use is also extremely simple:
$ memcached-tool Host Name: Port option
You do not need to specify options when viewing slabs usage, so you can use the following command:
$ memcached-tool Host Name: Port
The information obtained is as follows:
# item_size Max_age 1mb_pages Count full?1 104B1394292S1215 12249628Yes2 136B1456795S the 400919Yes3 176B1339587S - 196567Yes4 224B1360926S109 510221Yes5 280B1570071S the 183452Yes6 352B1592051S the 229197Yes7 theB1517732S the 157183Yes8 552B1460821S + 117697Yes9 696B1521917S143 215308YesTen 872B1695035S205 246162Yes One 1.1Kb1681650S233 221968Yes A 1.3Kb1603363S241 183621Yes - 1.7Kb1634218S94 57197Yes - 2.1Kb1695038S the 36488Yes the 2.6Kb1747075S $ 25203Yes - 3.3Kb1760661S + 24167Yes
The meanings of each column are:
Column |
Meaning |
# |
Slab class Number |
Item_size |
Chunk size |
Max_age |
Lifetime of oldest record in LRU |
1mb_pages |
Number of pages assigned 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 highly recommended.
Summary of memory storage
This paper simply explains the caching mechanism and tuning method of memcached. I hope readers can understand the principle of memcached memory management and its advantages and disadvantages.
Next time, we will continue to explain the principles of LRU and expire, as well as the latest development direction of memcached-expandable system (pluggable Architecher).
Memcached Complete Anatomy Series Tutorial "Turn" memcached Complete Anatomy Series Tutorial –2. Understanding memcached Memory Storage