服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 在memcached中意外的（？）高“浪费”的内存
Intereting Posts
使用ext4文件系统在64位RHEL6操作系统上设置配额 为什么我的AWS实例突然变得无反应报告高度“被盗”的CPU HP DL580 HDD风扇问题 MySQLconfiguration文件中的环境variables？ 使用Clonezilla Server Edition和多个多播恢复操作 正确configurationPostfix以确保安全（SASL + TLS） Oracle甚至在内存和交换空间充足的情况下调用了OOM杀手？ 是否有可能从一个实例types升级/降级到完全不同的实例types？ Posfix的smtpd_sasl_path似乎不适用于我 EC2自动缩放AMI并自动从快照中附加新的EBD 不能SSH到谷歌电脑引擎 更改为env：flex在app.yaml中引入了redirect s3cmd只放入目标存储桶中不存在的文件 域用户不能使用域名访问服务器文件共享。 使用服务器IP地址和Netbios名称正常工作 WinXP如何通过USB隧道LPT

在memcached中意外的（？）高“浪费”的内存

更新后，请参阅较长的问题（对不起）的底部。

看看我们的memcached状态我想我已经发现了一个我以前没有意识到的问题。 似乎我们有一个奇怪的高度浪费的空间。 我用phpmemcacheadmin检查了一下，发现这个图像盯着我：

memcached缓存大小的图形

现在我的印象是，最坏的情况是50％的浪费，尽pipe我是第一个承认不了解所有细节的人。 我已经阅读 – 除了其他 – 这个页面确实有点老，但我们的版本的memcached。 我想我很了解这个系统是如何工作的（ 例如 ）我相信，但我很难理解我们如何能够达到76％的浪费空间。

phpmemcacheadmin显示的驱逐率是2 ev/s ，所以这里有一些问题。

  • 主要问题是： 我能做些什么来解决这个问题 。 我可以扔更多的内存（有一些额外的可用我想），也许我应该摆弄slabconfiguration（这是甚至有可能与此版本？），也许还有其他的select？ 升级memcached版本不是一个快速可用的选项。

  • 出于好奇，第二个问题当然是如果75％（和上升）浪费空间的速度是预期的，如果是的话，为什么呢？

系统：目前我不能做任何事情，我知道memcached版本不是最新的，但这些是我已经处理的卡片。

  • Memcached 1.4.5
  • Apache 2.2.17
  • PHP 5.3.5

作为对@DavidSchwartz答案的回应：这是phpmemcacheadmin产生的slab统计信息：（这里有更多的btw平板）

（ 我也在这里以稍后的文本格式粘贴统计 ）

板坯细节

UPDATE

我用-f 1.5重启了守护进程，看起来非常好。 经过一些变暖，我们有一个使用/浪费50/50。 但是，和以前一样，我们白天的时间越来越长（白天变得越来越忙），现在开始回落到现在的水平：30/70，浪费还在上升。 除此之外，我还不知道“浪费”是从哪里来的。 我看到这块板： 

 **Slab 5 Stats** Chunk Size 496.0 Bytes Used Chunk 77502 [24.6 %] Total Chunk 314986 Total Page 149 Wasted 117.3 MBytes Hits 30.9 Request/sec Evicted 0

它不是满的，它没有驱逐，但它正在浪费117.3 MBytes。 我做的快速计算（纠正我，如果我错了）是：

  • 前一个slab的块大小为328，所以最坏的情况是这个slab填充了329个字节的块。
  • 这意味着它浪费了每个使用的块大小为167字节= 12942834字节= 12.3 MB

那么其他105MB的浪费从哪里来呢？ 它是旁边的大兄弟看起来像这样： 

 **Slab 6 Stats** Chunk Size 744.0 Bytes Used Chunk 17488 [31.0 %] Total Chunk 56360 Total Page 40 Wasted 31.1 MBytes Hits 107.7 Request/sec Evicted 1109

这个问题已经有一年了，我不知道你是否find了答案，但是我想说你对“浪费”的看法是错误的。

浪费的内存在内存中分配，所以不能被其他应用程序使用，但仍然可用于memcached。

为了简化说明，假设你有一个3MB RAM的memcache，带有3个slab： 

 slab class 1: chunk size 10485 perslab 100 slab class 2: chunk size 104857 perslab 10 slab class 3: chunk size 1048576 perslab 1

执行一个10K大小的单一“设置”。 你会看到你的统计（大致），你有： 

 0.03% used 66.6% free 33% wasted

这是因为memcached从“slab class 1”中分配了一个块，并且该块的99％的内存被“浪费了”，1％被“使用”。这并不意味着slab和为该slab分配的内存不见了。

执行另一个10K大小的“集”。 这一次你会看到： 

 0.06% used 66.6% free 32.7% wasted

所以现在你正在使用slab 1中的100个分配块中的2个，“浪费”的统计数据下降，并且使用统计数据增加。

使用％+浪费百分比等于100％没有任何错误。 这并不意味着你没有更多的内存，它只是意味着你至less分配了每个板块的一个块。

要看到这个问题是一个100K大小的“集”和另一个1000K大小

现在你会看到 

 36.6% used 0% free 63.3% wasted

你可能有很多非常小的物体。 通常，最小的板坯保存104字节的条目。 如果你有很多条目只是把一个整数映射到另一个整数，你可以得到高达85％的浪费。

您可以在文章Memcached中find关于如何调整这个小对象的信息 。

我有这个问题，并从memcached迁移到redis（没有基于磁盘的保存）。 我知道这可能是不可能的，但你可以尝试一下，并留意内存碎片。 你甚至可以打开持久性来解决重启时的“旧caching”问题。