|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-09-10
贴一个感觉不错的memchached的系列文档
也可以通过下面的链接下载 http://bigweb.group.iteye.com/group/topic/6838 |
| 返回顶楼 | |
|
发表时间：2008-09-10
sizhefang 写道 贴一个感觉不错的memchached的系列文档
也可以通过下面的链接下载 http://bigweb.group.iteye.com/group/topic/6838 谢大家对memcached的补充,不过这份资料在第一页quake wang大已经推荐过了 ---------------------------------------------------------- 这份文档说是全面,其实还是不全面,因为这两个japanese并没有告诉我们LRU是针对slab的,而这一点是本文的主题,其他描述都是铺垫,因为其他描述网上到处都是,恰恰针对slab的LRU网上到处都没有,本文也可以算是对这份文档的一个补充吧 |
| 返回顶楼 | |
|
发表时间：2008-09-12
谢大家对memcached的补充,不过这份资料在第一页quake wang大已经推荐过了
⇒哈哈，不好意思。没有仔细看所有人的回复，只是感觉这篇文档是目前见过的 关于memcached的比较不错的文档。如果哪位家里人手里还有不错的文档希望 也能共享一下，因为最近我也在搞memcached这个东东～～ |
| 返回顶楼 | |
|
发表时间：2008-12-04
最后修改：2008-12-04
认为对楼主两点说的不清楚的地方：
1. 引用 每个slab下又有若干个page
2. 引用 这就解释了为什么我的内存还有40%的时候LRU就执行了，因为我的其他slab中的chunk_size都远大于我的value，所以我的value根本不会放到那几个slab中，而只会放到和我的value最接近的chunk所在的slab中(而这些slab早就满了，郁闷了)。这就导致了我的数据被不停的覆盖，后者覆盖前者。
下面是从其他帖子里的摘录： 引用 Slab Allocation的主要术语 Page 分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。 Chunk 用于缓存记录的内存空间。 Slab Class 特定大小的chunk的组。 引用 开启memcached: memcached -d -m 10 -l 192.168.1.21 -p 11222 -u userA 这行命令会开启memcached服务,memcached在192.168.1.21:112222上面进行监听, 同时设置memcached使用的最大内存为10MB, memcached一开始并不会一下子申请10MB的内存, 而是在需要的时候才会使用malloc申请内存,当申请内存达到10MB时就不会再申请. 为了减少管理内存碎片的麻烦,当你需要通过memcached往缓存里面保存一个数据时, memcached给这个数据提供一个固定大小的内存块(chunk),比如数据的长度是100bytes,那么memcached提供一个大小为128b的chunk来存储该数据,chunk块的大小可以为64B,128B,256B...1024KB.使用何种大小的chunk块是由memcache根据数据的长度来决定的. 当你第一次往memcached存储数据时, memcached会去申请1MB的内存, 把该块内存称为一个slab, 也称为一个page, 如果可以存储这个数据的最佳的chunk大小为128B,那么memcached会把刚申请的slab以128B为单位进行分割成8192块. 当这页slab的所有chunk都被用完时,并且继续有数据需要存储在128B的chunk里面时,如果已经申请的内存小于最大可申请内存10MB时,memcached继续去申请1M内存,继续以128B为单位进行分割再进行存储;如果已经无法继续申请内存,那么mamcached会先根据LRU算法把队列里面最久没有被使用到的chunk进行释放后,再将该chunk用于存储. chunk属于某个slab,slabs由memcached进行分组管理,以同样chunk大小进行分割的slab属于同一组. 我的理解： 第一点首先楼主说一个slab下有多个page，我理解page数指的是memcache分配的某一个型号的slab的数量。 第二点我的理解是如果还有可分配的内存，则不会覆盖1号slab的数据，如果内存没有可分配的了，则会覆盖1号slab比较旧的数据。此时你说“ 我的内存还有40%的时候LRU就执行了”，其实此时已经没有内存可分配了，因为这40%内存已经分配给了其他号的slab，所以1号slab的旧数据会被LRU。 如果我理解错了，希望大家拍砖，并把这个问题说清楚，不要迷惑更多的人！ --- 不是说楼主迷惑人，是网上各种说法迷惑人 ：），至少我是花了一晚上时间看文档 测试才自认为搞清楚了。 楼主不要激动 呵呵 ，绝对支持你的分享精神 |
| 返回顶楼 | |
|
发表时间：2008-12-04
ＭＥＭＣＡＣＨＥＤ不适合要求数据可靠的应用， 要可靠的数据， 内存数据库是不错的选择。
|
| 返回顶楼 | |
|
发表时间：2008-12-04
楼主肯定是因为数据的长度大小不相同的紊乱程度造成的， 如果说还有４０％的内存， 肯定还会继续分配的。 另外， 建议你对于长度超过一定大小的进行压缩。
|
| 返回顶楼 | |
|
发表时间：2008-12-04
最后修改：2008-12-04
tongjian 写道 认为楼主有两个概念介绍错了
如果我理解错了，希望大家拍砖，并把这个问题说清楚，不要迷惑更多的人！ 你确实理解错了，事情正如我所说，不信的话你可以看memcached的源代码，既然认为我介绍错了，我也非常希望你把你的分析或者实验数据拿出来。 还有即使我错了，我想的目的也不是去迷惑其他人。本来是把自己的经验拿出来的，现在被说成了是迷惑其他人，呵呵。 当然说那么多没有用，拿证据出来证明我是错的吧 －－－－－－－－－－－－－－－－－－－－－－－－ tongjian 写道 1.page是描述slab大小的。 不管你去网上找什么资料，都是和我的描述基本上是保持一直的。 去看看memcached的原代码吧 tongjian 写道 2.第二点需要一些数据证明一下，假如我有1千万+量级的数据，数据大小都是80b， 那按楼主的意思，无论memcahced内存开多大，都最多只会用一个slab大小，即1M。 那memcached也太弱了，我对这个观点表示怀疑，找时间我会测试一下。 这一点完全你是没有理解，我在正文上早就说了，一个slab会有多个page，明白不？怎么可能只用1m(只是预先分配1m，不是说只能使用1m，当这1m的数据满了之后，会重新分配一个page给这个slab，一旦到达使用内存的上限就不会再分配新的page了，新数据进来会有针对该slab的LRU，而且这个LRU只是针对该双向链表的前50个元素)，看清楚文章再发言可以吗 |
| 返回顶楼 | |
|
发表时间：2008-12-04
最后修改：2008-12-04
哦，还有一点忘记说了，我们把memcache扩展了之后，完全改变了LRU的行为，而且可以通过key的前缀来控制这个key是需要被LRU，当然做这些事情的前提是充分理解memcached的原理。
|
| 返回顶楼 | |
|
发表时间：2008-12-04
最后修改：2008-12-04
补充：
晕了，本来想编辑帖子，一不小心把上边帖子引用楼主的内容删了。还是再回一个吧 两点误解的补充： 第一点首先楼主说一个slab下有多个page，我理解page数指的是某一个slab的数量。 第二点我的理解是如果还有可分配的内存，则不会覆盖1号slab的数据，如果内存没有可分配的了，则会覆盖1号slab比较旧的数据。此时你说“我的内存还有40%的时候LRU就执行了”，其实此时已经没有内存可分配了，因为这40%内存已经分配给了其他号的slab，所以1号slab的旧数据会被LRU。 还有 “Keep in mind that memcached is a cache not a database. It is fast, but not reliable storage.” 不知大家怎么理解的？ |
| 返回顶楼 | |
|
发表时间：2008-12-04
sdh5724 写道 ＭＥＭＣＡＣＨＥＤ不适合要求数据可靠的应用， 要可靠的数据， 内存数据库是不错的选择。
非常同意，“Keep in mind that memcached is a cache not a database. It is fast, but not reliable storage.” 所以不要认为memcached是个好东西就是万能的。 |
| 返回顶楼 | |
