memcached学习二

memcached学习二
memcached的内存管理：
在以前memcached内存管理是通过c语言直接malloc，free来向操作系统申请和释放内存资源的，在不断重复申请和释放的过程中，会造成碎片化的内存片段无法再使用，造成内存碎片化，加重操作系统内存的管理的负担，悲观情况下，可能会导致操作系统比memcached进程本身还慢。现在memcached默认情况下采用名为slab allocator的机制分配，管理内存。
slab allocator的基本原理是将分配的内存分隔成特定长度的块，已完全解决内存碎片问题。将分配的内存分割成特定长度的块，并把尺寸相同的块分成组（chunk的集合）。而分配的内存不会释放，会被重复使用。
page：分配给slab的内存空间，默认是1MB，分配给slab后，按照slab的大小切分为chunk。
chunk：用于缓存记录的内存空间
slab：特定大小的chunk组
memcached根据收到的数据大小，选择合适大小的slab。memcachd通过查找内部保存的slab内空闲chunk列表来选择chunk。
任何事务都有其两面性，memcached的slab allocator管理内存有其优点，那必然也会有其缺点：
slab allocator管理内存的缺点：
由于分配的内存片段大小是固定的，所以无法有效的利用全部内存。这个问题现在还没有解决办法，只能预先确定客户端发送的数据的公用大小，或者是缓存相同数据的情况下，只要使用适合的数据大小的组合就可以减少浪费。目前无法自定义chunk的大小，只能通过参数来调整内存分配的增长因子（grow factor）。

memcached的增长因子（grow factor）：
memcached在启动时可以通过参数-f在某种程度上控制slab之间的差异。默认为1.25，在这个选项出现之前是2（power of 2）。在将memcached引入生产部署时，最好是重新计算数据的预期增长平均长度，调整增长因子大小，获得一个最佳的设置，减少内存资源的浪费。

---

memcached的一些工具
通过安装libmemcached这个面向C/C++语言的客户端库，就会安装memstat命令，可以获得memcached服务器额信息。
memstat –servers=127.0.0.1:11215
Listing 1 Server
Server: 127.0.0.1 (11215)
pid: 16711
uptime: 151
time: 1439953081
version: 1.4.24
pointer_size: 64
rusage_user: 0.2999
rusage_system: 0.2999
curr_items: 0
total_items: 0
bytes: 0
curr_connections: 10
total_connections: 11
connection_structures: 11
cmd_get: 0
cmd_set: 0
get_hits: 0
get_misses: 0
evictions: 0
bytes_read: 0
bytes_written: 0
limit_maxbytes: 10485760
threads: 4

查看slabs的使用情况：
memcached的创造者Brad写的名为memcached-tool的perl脚本，可以很方便的获得slab的使用情况。
memcached-tool 172.21.19.56:11212
# Item_Size Max_age Pages Count Full? Evicted Evict_Time OOM
1 96B 6852931s 30 321289 no 0 0 0
2 120B 10967792s 539 28964 no 0 0 0
3 152B 10710871s 3 2100 no 0 0 0
4 192B 10967622s 1 33 no 0 0 0
5 240B 10967326s 1 62 no 0 0 0
6 304B 10969503s 1 12 no 0 0 0
7 384B 10966988s 1 507 no 0 0 0
8 480B 10452022s 23 40928 no 0 0 0
9 600B 10969465s 1 111 no 0 0 0
10 752B 10967673s 5 3983 no 0 0 0
11 944B 10967508s 9 7829 no 0 0 0
12 1.2K 10969471s 1 410 no 0 0 0
13 1.4K 10969460s 1 299 no 0 0 0
14 1.8K 10969377s 4 153 no 0 0 0
15 2.3K 10969161s 2 78 no 0 0 0
16 2.8K 10967799s 3 51 no 0 0 0
17 3.5K 10968881s 3 5 no 0 0 0
18 4.4K 10967752s 3 1 no 0 0 0
19 5.5K 0s 2 0 no 0 0 0
20 6.9K 0s 2 0 no 0 0 0
21 8.7K 0s 2 0 no 0 0 0
22 10.8K 0s 2 0 no 0 0 0
23 13.6K 0s 2 0 no 0 0 0
24 16.9K 8053828s 2 98 no 0 0 0
25 21.2K 8029779s 1 26 no 0 0 0
26 26.5K 7836735s 1 7 no 0 0 0
27 33.1K 0s 1 0 no 0 0 0
28 41.4K 0s 1 0 no 0 0 0
29 51.7K 0s 1 0 no 0 0 0
30 64.7K 0s 1 0 no 0 0 0
31 80.9K 0s 1 0 no 0 0 0
32 101.1K 0s 1 0 no 0 0 0
33 126.3K 0s 1 0 no 0 0 0
34 157.9K 0s 1 0 no 0 0 0
35 197.4K 0s 2 0 no 0 0 0
36 246.8K 0s 2 0 no 0 0 0
37 308.5K 0s 3 0 no 0 0 0
38 385.6K 0s 4 0 no 0 0 0
39 482.0K 0s 4 0 no 0 0 0
40 602.5K 0s 7 0 yes 0 0 0
slab class编号
Item_Size Chunk大小
Max_age LRU内最旧的记录的生存时间
1MB_pages 分配给Slab的页数
Count Slab内的记录数
Full? Slab内是否含有空闲chunk

---

因为memcached的天生基因是缓存，其本身任何的持久化策略，所以数据不会永久的保存在服务器上，而memcached不会释放已分配的内存。数据超过内存空间限制时，会采用LRU算法清空数据来满足新的数据需求。其存储空间可以重复利用。
memcached内部不会监视数据是否过期，而是在get是查看记录的时间戳，检查记录是否过期。这种技术被称为lazy expiration。
memcached可以通过启动时的-M参数来禁止使用LRU机制管理。但是memcached毕竟不是存储而是缓存，随意推荐还是使用LRU管理。

---

memcached的未来

memcached有两个大的目标正在努力实现，一个是二进制协议的实现，一个是外部引擎的加载功能。
二进制协议的实现：
memcached现在使用的是简单的文本协议处理命令，这需要对文本协议进行解析。如果采用二进制协议可以去除文本协议解析，使得memcached在性能上更上一层楼，还能减少由于文本协议带来的漏洞。

外部引擎的加载功能：
现在世界上有许多由memcached衍生出来的软件，希望永久保存数据、实现数据冗余等，即使牺牲一些性能也是可以接受的。

现阶段，本人所在的公司还是简单的使用memcached作为缓存系统，并没有在前端做分布式，memcached是单点，存在memcached挂起，后端数据库并发骤增，造成“雪崩”的情况。