memcached 中的意外（？）高“浪費”記憶體
已更新，請參閱冗長（抱歉）問題的底部。
查看我們的 memcached 統計資訊，我想我發現了一個我以前不知道的問題。似乎我們有大量浪費的空間。我檢查了phpmemcacheadmin的更改，發現這張圖片盯著我看：
現在我的印像是，最壞的情況是有 50% 的浪費，儘管我是第一個承認不知道所有細節的人。我已經閱讀了——除其他外——這個頁面確實有點舊，但我們的 memcached 版本也是如此。我想我確實理解系統是如何工作的（例如）我相信，但我很難理解我們如何才能達到 76% 的浪費空間。
phpmemcacheadmin 顯示的驅逐率是
2 ev/s，所以這裡有一些問題。
- 主要問題是：我能做些什麼來解決這個問題。我可以扔更多的記憶體（我認為有一些額外的可用），也許我應該擺弄slab配置（這個版本甚至可能嗎？），也許還有其他選擇？升級 memcached 版本不是一個快速可用的選項。
- 出於好奇，第二個問題當然是是否預計 75%（並且還在上升）的空間浪費率是預期的，如果是，為什麼。
系統：目前這不是我能做的事情，我知道memcached版本不是最新的，但這些是我收到的卡片。
- 記憶體記憶體 1.4.5
- 阿帕奇 2.2.17
- PHP 5.3.5
作為對@DavidSchwartz 回答的回應：這裡是 phpmemcacheadmin 生成的平板統計資訊：（順便說一句，這些平板更多）
更新
我用 -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 MB。我做的快速計算（如果我錯了，請糾正我）是：
- 前一個slab的塊大小為328，所以最壞的情況是這個slab被329字節的塊填充。
- 這意味著每個使用的塊浪費 167 字節 = 12942834 字節 = 12.3 MB
那麼，另外105 MB 的浪費是從哪裡來的呢？旁邊的大哥長這樣：
**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
這個問題已經過去一年了，我不知道你是否找到了答案，但我想說你對“浪費”的看法是錯誤的。
浪費的記憶體被分配在記憶體中，因此它不能被其他應用程序使用，但它仍然可用於 memcached。
為了簡化解釋，假設您有一個記憶體記憶體為 3MB 的記憶體和 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”分配了一個塊，並且該slab 99% 的記憶體被“浪費”，1% 被“使用”這並不意味著slab 和為該slab 分配的記憶體消失了。
執行另一個 10k 大小的“集合”。這次你會看到：
0.06% used 66.6% free 32.7% wasted所以現在你在slab 1中使用了100個分配的塊中的2個，“浪費”的統計數據下降了，使用的統計數據增加了。
used% + wasted% 等於 100% 沒有錯。這並不意味著你沒有更多的記憶體，它只是意味著你從每個slab中分配了至少一個塊。
要查看這個問題，一個大小為 100k 的“集合”和另一個大小為 1000k 的“集合”
現在你會看到
36.6% used 0% free 63.3% wasted