Memcached内存分配优化及使用问题

前几天做了个Memcached的思考，并测试了一些数据，是关于如何提高Memcached内存使用率的问题。
在启动memcached的时候可以加-f参数和-n参数。-f指定各slab里面chunk大小的变化比例，默认1.25，-n指定slab里面chunk大小从多少开始。
使用memcache_add($memcache_obj, md5(rand()), str_repeat(md5(rand()),10), false,80000 );向memcache中持续灌入数据。

Memcached –d start –m 50 启动memcache,增长系数默认为1.25
结果：
2011-03-28 11:15:37:SAR:localh~211: 10 0 0 0 0/0% 0 5 265 50M 0% 0 0 0 4/0/0
2011-03-28 11:15:40:SAR:localh~211: 11 0 0 530 0/0% 0 192K 4K 50M 1% 797 530 0 4/0/0
2011-03-28 11:15:43:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 17% 21K 13K 0 4/0/1
2011-03-28 11:15:46:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 104K 50M 48% 61K 13K 0 4/1/1
2011-03-28 11:15:49:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 102K 50M 77% 98K 13K 580 4/1/2
2011-03-28 11:15:52:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 103K 50M 92% 116K 13K 13K 4/1/3
2011-03-28 11:15:55:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 92% 116K 13K 13K 4/2/4
2011-03-28 11:15:58:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 107K 50M 92% 116K 13K 13K 4/2/5
2011-03-28 11:16:01:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 101K 50M 92% 116K 13K 13K 4/3/6

使用率稳定在92%，存储116k条
stats slabs
STAT 8:chunk_size 440
STAT 8:chunks_per_page 2383
STAT 8:total_pages 50
STAT 8:total_chunks 119150
STAT 8:used_chunks 119150

使用了大小为440字节的chunk。 使用了id为8的slab

Memcached –d start –m 50 –f 2 增长系数为2
结果：
2011-03-28 11:17:53:SAR:localh~211: 10 0 0 0 0/0% 0 5 267 50M 0% 0 0 0 4/0/0
2011-03-28 11:17:56:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 107K 50M 16% 20K 13K 0 4/0/0
2011-03-28 11:17:59:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 47% 60K 13K 0 4/1/1
2011-03-28 11:18:02:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 63% 80K 13K 13K 4/1/2
2011-03-28 11:18:05:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 105K 50M 63% 80K 13K 13K 4/1/3
2011-03-28 11:18:08:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 108K 50M 63% 80K 13K 13K 4/2/4
2011-03-28 11:18:11:SAR:localh~211: 11 0 0 13K 0/0% 0 5M 106K 50M 63% 80K 13K 13K 4/2/5

使用率稳定在63%，存储80k条。
STAT 4:chunk_size 640
STAT 4:chunks_per_page 1638
STAT 4:total_pages 50
STAT 4:total_chunks 81900
STAT 4:used_chunks 81900

使用了大小为640的chunk，使用了id为4的slab

Memcached –d start –m 50 –f 1.001 –n 375 增长率为1.001 (memcache要求增长率必须大于1)
结果：
2011-03-28 14:40:09:SAR:127.0.~211: 11 0 0 12K 0/0% 0 4M 100K 50M 98% 124K 12K 10K 4/1/3
2011-03-28 14:40:10:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 104K 50M 99% 125K 13K 13K 4/1/3
2011-03-28 14:40:11:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 106K 50M 99% 125K 13K 13K 4/2/4

使用率稳定在99%，存储125k条
STAT 1:chunk_size 408
STAT 1:chunks_per_page 2570
STAT 1:total_pages 6
STAT 1:total_chunks 15420
STAT 1:used_chunks 15022

使用了大小为408的chunk，使用了id为1的slab

可见调整-f和-n的值可有效提高memcache对内存的使用率。
不过需要注意的是，以上测试数据使用了同长度数据，对于长度不定长的数据，需要根据整体数据确定-f和-n的值。
经过我的测试slab的id值最大为200，若id为199的slab中chunk仍小于数据长度，那么需要将数据存放在id为200的slab中，该slab中的chunk大小为1m，造成内存的巨大浪费。
memcached -d start -m 50 -f 1.001 -n 100
2011-03-28 14:51:15:SAR:127.0.~211: 11 0 0 13K 0/0% 0 5M 101K 50M 0% 50 13K 13K 4/1/2

内存使用率约等于0，存储50条数据
STAT 200:chunk_size 1048576
STAT 200:chunks_per_page 1
STAT 200:total_pages 50
STAT 200:total_chunks 50
STAT 200:used_chunks 50

使用了大小为1m的chunk，使用了id为200的slab

现在还有一个问题：
STAT 1:chunk_size 408
STAT 1:chunks_per_page 2570
一个1m大小slab中存放了2570个大小为408的chunk，可见并没有放满，剩余的空间就被浪费了。对于这种情况，每个slab浪费的内存只有几百个字节，可以忽略不计，但是假如chunk大小为几十上百k的时候，空间浪费情况就很客观了。这时可在memcached启动时添加-I（大写的i）参数来改变slab的大小

文章转自：http://blog.csdn.net/ago52030/article/details/6902026

时间： 2024-10-18 00:30:04

Memcached内存分配优化及使用问题的相关文章

memcached内存分配

1. page(页)为内存分配的最小单位 Memcached 的内存分配以page为单位,默认情况下一个page是1M,可以通过-I参数在启动时指定.如果需要申请内存时,memcached会划分出一个新的 page并分配给需要的slab区域.page一旦被分配在重启前不会被回收或者重新分配 2. Chunk(块)才是存放缓存数据的单位. Chunk 是一系列固定的内存空间,这个大小就是管理它的slab的最大存放大小.例如:slab 1的所有chunk都是104byte,而slab 4的所有chu

托管堆内存分配优化

内存问题概述 和CPU一样,内存也是一个直接影响服务端性能的重要的硬件资源. 一般来说,如果服务端内存不足,从导致以下两个问题产生: 1. 导致服务端把一些原本要写到内存中的数据,写到硬盘上面.这样不仅仅加大了CPU和磁盘的I/O操作,同时也延长了读取这些数据的时间. 2. 阻止了一些缓存策略的使用. 对于内存不足,一直最快最直接的方式就是去买内存条加在服务器上面.但是这样存在一个隐患的问题就是:如果加了新的内存之后,服务端又面临内存不足的问题,我们不可能无止境的加内存条,那么我们就必须从站点本

memcached内存分配机制

在C中,使用malloc分配内存时会产生内存碎片,即空闲零碎的空间无法利用. Memcached中的Slab Allocator机制缓解这一问题. 基本原理: 按照预先规定的大小,将内存分成数个slab仓库,然后将各仓库分割成特定长度的块(chunk),并把尺寸相同的块分成组,以完全解决内存碎片问题 Memcached根据收到的数据的大小,选择最适合数据大小的slab.Memcached保存slab内空闲chunk的列表,根据该列表选择chunk,然后将数据缓存于其中. 根据缓存数据大小的变化规

c++14对内存分配性能的重大优化

Table of Contents 1. 本质需求 2. 存在的问题 3. 解决方案 简述, C++14标准对内存优化的描述修改, 会让编译器引入类似TCMalloc的内存分配优化策略, 而不拘泥于原来的有一个new语句,就分配一次内存的傻傻的情况. 因此有理由相信用C++14的编译器编译出来的c++程序在内存分配上性能会有较多提升. 下面的文字来源于clang编译器提供的文档, 我对其主要内容进行了意译. 个人感觉是, 不再需要引入TCMalloc库来帮助提升性能, 直接使用c++14就行了.

Memcache内存分配策略

一.Memcache内存分配机制 关于这个机制网上有很多解释的,我个人的总结如下. Page为内存分配的最小单位. Memcached的内存分配以page为单位,默认情况下一个page是1M,可以通过-I参数在启动时指定.如果需要申请内存 时,memcached会划分出一个新的page并分配给需要的slab区域.page一旦被分配在重启前不会被回收或者重新分配(page ressign已经从1.2.8版移除了)  Slabs划分数据空间. Memcached并不是将所有大小的数据都放在一起的,而

memcached学习——memcached的内存分配机制Slab Allocation、内存使用机制LRU、常用监控记录（四）

内存分配机制Slab Allocation 本文参考博客:https://my.oschina.net/bieber/blog/505458 Memcached的内存分配是以slabs为单位的,会根据初始chunk大小.增长因子.存储数据的大小实际划分出多个不同的slabs class,slab class中包含若干个等大小的trunk和一个固定48byte的item信息.trunk是按页存储的,每一页成为一个page(默认1M). 1.slabs.slab class.page三者关系: sl

C++ Primer 学习笔记_98_特殊工具与技术 --优化内存分配

特殊工具与技术 --优化内存分配 引言: C++的内存分配是一种类型化操作:new为特定类型分配内存,并在新分配的内存中构造该类型的一个对象.new表达式自动运行合适的构造函数来初始化每个动态分配的类类型对象. new基于每个对象分配内存的事实可能会对某些类强加不可接受的运行时开销,这样的类可能需要使用用户级的类类型对象分配能够更快一些.这样的类使用的通用策略是,预先分配用于创建新对象的内存,需要时在预先分配的内存中构造每个新对象. 另外一些类希望按最小尺寸为自己的数据成员分配需要的内存.例如,

C++ Primer 学习笔记_99_特殊工具与技术 --优化内存分配[续１]

特殊工具与技术 --优化内存分配[续1] 三.operator new函数和operator delete 函数 – 分配但不初始化内存 首先,需要对new和delete表达式怎样工作有更多的理解.当使用new表达式 string *sp = new string("initialized"); 的时候,实际上发生三个步骤: 1)首先,表达式调用名为operator new 的标准库函数,分配足够大的原始的未类型化的内存,以保存指定类型的一个对象; 2)接下来,运行该类型的一个构造函数

Weblogic admin server与manager server内存分配缺陷优化

1.admin server与manager server内存分配缺陷描述 Weblogic服务器一般会为每一个业务系统设计一个或多个域(domain),每一个域(domain)服务主体必须由Admin server和Manage Server两类Server组成,两类Server都需要占用一定的内存资源(人工配置),Manage Server负责运行业务,Admin Server则只负责管理Manage Server,只是在启动Weblogic和需要调整Weblogic配置时才使用,启动Web