Memcached存儲單個item最大數據是在1MB內，假設數據超過1M,存取set和get是都是返回false，並且引起性能的問題。
我們之前對排行榜的數據進行緩存。因為排行榜在我們全部sql select查詢里面占了30%，並且我們排行榜每小時更新一次，所以必須對數據做緩存。
為了清除緩存方便，把全部的用戶的數據放在同一key中，因為memcached:set的時候沒有壓縮數據。在測試服測試的時候，沒發現問題。當上線的時候，結果發現。在線人數剛剛490人的時候，serverload average飄到7.9。然后我們去掉緩存，一下子就下降到0.59。
所以Memcahce不適合緩存大數據，超過1MB的數據，能夠考慮在client壓縮或拆分到多個key中。大的數據在進行load和uppack到內存的時候須要花非常長時間，從而減少server的性能。
Memcached支持最大的存儲對象為1M。這個值由其內存分配機制決定的。
memcached默認情況下採用了名為Slab Allocator的機制分配、管理內存。在該機制出現曾經，內存的分配是通過對全部記錄簡單地進行malloc和free來進行的。
可是，這樣的方式會導致內存碎片，加重操作系統內存管理器的負擔，最壞的情況下。會導致操作系統比memcached進程本身還慢。Slab Allocator就是為解決該問題而誕生的。
Slab Allocator的基本原理是依照預先規定的大小，將分配的內存切割成特定長度的塊。以全然解決內存碎片問題.
今天（2012-03-16）我們又一次測試了memcached ::set的數據大小。可能是我們用php的memcached擴展是最新版，set數據的時候是默認壓縮的。set 數據：
$ac = new memcahed();
$data = str_repeat('a', 1024* 1024); //1M的數據
$r = $ac->set('key', $data, 9999);
//或者
$data = str_repeat('a', 1024* 1024*100);//100M的數據
$r = $ac->set('key', $data, 9999);
不論是1M的數據還是100M的數據，都能set成功。
后來我發現，memcachedset數據的時候是默認壓縮的。
因為這個這個是反復的字符串，壓縮率高達1000倍。因此100M的數據壓縮后實際也就100k而已。
當我設置：
$ac->setOption(memcahed::OPT_COMPRESSION,0); //不壓縮存儲數據。
$data = str_repeat('a', 1024* 1024); //1M數據
$r = $ac->set('key', $data, 9999);//1M的數據set不成功。
也就是說memcached server不能存儲超過1M的數據，可是經過client壓縮數據后，僅僅要小於1M的數據都能存儲成功。
memcached相關知識：
1、memcached的基本設置
1）啟動Memcache的server端
# /usr/local/bin/memcached -d -m 10 -u root -l 192.168.0.200 -p 12000 -c 256 -P /tmp/memcached.pid
-d選項是啟動一個守護進程，
-m是分配給Memcache使用的內存數量，單位是MB，我這里是10MB。
-u是執行Memcache的用戶。我這里是root。
-l是監聽的serverIP地址。假設有多個地址的話，我這里指定了server的IP地址192.168.0.200，
-p是設置Memcache監聽的port。我這里設置了12000，最好是1024以上的port，
-c選項是最大執行的並發連接數，默認是1024，我這里設置了256，依照你server的負載量來設定，
-P是設置保存Memcache的pid文件，我這里是保存在 /tmp/memcached.pid。
2）假設要結束Memcache進程。運行：
# kill `cat /tmp/memcached.pid`
哈希算法將隨意長度的二進制值映射為固定長度的較小二進制值。這個小的二進制值稱為哈希值。哈希值是一段數據唯一且極其緊湊的數值表示形式。假設散列一段明文並且哪怕僅僅更改該
段落的一個字母。隨后的哈希都將產生不同的值。要找到散列為同一個值的兩個不同的輸入，在計算上是不可能的。
2、適用memcached的業務場景？
1）假設站點包括了訪問量非常大的動態網頁。因而數據庫的負載將會非常高。因為大部分數據庫請求都是讀操作，那么memcached能夠顯著地減小數據庫負載。
2）假設數據庫server的負載比較低但CPU使用率非常高，這時能夠緩存計算好的結果（ computed objects ）和渲染后的網頁模板（enderred templates）。
3）利用memcached能夠緩存session數據、暫時數據以降低對他們的數據庫寫操作。
4）緩存一些非常小可是被頻繁訪問的文件。
5）緩存Web 'services'（非IBM宣揚的Web Services，譯者注）或RSS feeds的結果.。
3、不適用memcached的業務場景？
1）緩存對象的大小大於1MB
Memcached本身就不是為了處理龐大的多媒體（large media）和巨大的二進制塊（streaming huge blobs）而設計的。
2）key的長度大於250字符
3）虛擬主機不讓執行memcached服務
假設應用本身托管在低端的虛擬私有server上。像vmware, xen這類虛擬化技術並不適合執行memcached。Memcached須要接管和控制大塊的內存。假設memcached管理 的內存被OS或 hypervisor交換出去，memcached的性能將大打折扣。
4）應用執行在不安全的環境中
Memcached為提供不論什么安全策略，只通過telnet就能夠訪問到memcached。
假設應用執行在共享的系統上，須要着重考慮安全問題。
5）業務本身須要的是持久化數據或者說須要的應該是database
4、 不能可以遍歷memcached中全部的item
這個操作的速度相對緩慢且堵塞其它的操作（這里的緩慢時相比memcached其它的命令）。memcached全部非調試（non-debug）命令，比如add, set, get, fulsh等不管
memcached中存儲了多少數據，它們的運行都僅僅消耗常量時間。
不論什么遍歷全部item的命令運行所消耗的時間。將隨着memcached中數據量的添加而添加。當其它命令由於等待（遍歷全部item的命令運行完成）而不能得到運行。因而堵塞將發生。
5、 memcached能接受的key的最大長度是250個字符memcached能接受的key的最大長度是250個字符。
須要注意的是，250是memcachedserver端內部的限制。假設使用的Memcachedclient支持"key的前綴"或類似特性。那么key（前綴+原始key）的最大長度是能夠超過250個字符的。推薦使用較短的key。這樣能夠節省內存和帶寬。
6、 單個item的大小被限制在1M byte之內由於內存分配器的算法就是這種。
具體的回答：
1）Memcached的內存存儲引擎，使用slabs來管理內存。內存被分成大小不等的slabs chunks（先分成大小相等的slabs，然后每一個slab被分成大小相等chunks，不同slab的chunk大小是不相等的）。chunk的大小依次從一個最小數開始，按某個因子增長。直到達到最大的可能值。假設最小值為400B，最大值是1MB，因子是1.20。各個slab的chunk的大小依次是：
slab1 - 400B；slab2 - 480B；slab3 - 576B ...slab中chunk越大。它和前面的slab之間的間隙就越大。因此。最大值越大。內存利用率越低。Memcached必須為每一個slab預先分配內存，因此假設設置了較小的因子和較大的最大值，會須要為Memcached提供很多其它的內存。
2）不要嘗試向memcached中存取非常大的數據，比如把巨大的網頁放到mencached中。由於將大數據load和unpack到內存中須要花費非常長的時間，從而導致系統的性能反而不好。假設確實須要存儲大於1MB的數據，能夠改動slabs.c：POWER_BLOCK的值。然后又一次編譯memcached；或者使用低效的malloc/free。另外。能夠使用數據庫、MogileFS等方案取代Memcached系統。
7、 memcached的內存分配器是怎樣工作的？為什么不適用malloc/free！？為何要使用slabs？
實際上，這是一個編譯時選項。默認會使用內部的slab分配器，並且確實應該使用內建的slab分配器。最早的時候，memcached僅僅使用malloc/free來管理內存。然而，這樣的方式不能與OS的內存管理曾經非常好地工作。重復地malloc/free造成了內存碎片，OS終於花費大量的時間去查找連續的內存塊來滿足malloc的請求，而不是執行memcached進程。slab分配器就是為了解決問題而生的。內存被分配並划分成chunks。一直被重復使用。由於內存被划分成大小不等的slabs。假設item的大小與被選擇存放它的slab不是非常合適的話，就會浪費一些內存。
8、memcached對item的過期時間有什么限制？
item對象的過期時間最長能夠達到30天。memcached把傳入的過期時間（時間段）解釋成時間點后。一旦到了這個時間點，memcached就把item置為失效狀態。這是一個簡單但obscure的機制。
9、什么是二進制協議，是否須要關注？
二進制協議嘗試為端提供一個更有效的、可靠的協議，降低client/server端因處理協議而產生的CPU時間。
依據Facebook的測試。解析ASCII協議是memcached中消耗CPU時間最多的
環節。
10、 memcached的內存分配器是怎樣工作的？為什么不適用malloc/free。？為何要使用slabs？
實際上。這是一個編譯時選項。默認會使用內部的slab分配器，並且確實應該使用內建的slab分配器。
最早的時候，memcached僅僅使用malloc/free來管理內存。然而，這樣的方式不能與OS的內存管理曾經非常好地工作。
重復地malloc/free造成了內存碎片，OS終於花費大量的時間去查找連續的內存塊來滿足malloc的請求，而不是執行memcached進程。slab分配器就是為了解決問題而生的。內存被分配並划分成chunks，一直被重復使用。由於內存被划分成大小不等的slabs。假設item的大小與被選擇存放它的slab不是非常合適的話，就會浪費一些內存。
11、memcached是原子的嗎？
全部的被發送到memcached的單個命令是全然原子的。假設您針對同一份數據同一時候發送了一個set命令和一個get命令，它們不會影響對方。它們將被串行化、先后運行。
即使在多線程模式。全部的命令都是原子的。然是，命令序列不是原子的。假設首先通過get命令獲取了一個item，改動了它，然后再把它set回memcached，系統不保證這個item沒有被其它進程（process，未必是操作系統中的進程）操作過。memcached 1.2.5以及更高版本號，提供了gets和cas命令，它們能夠解決上面的問題。
假設使用gets命令查詢某個key的item，memcached會返回該item當前值的唯一標識。
假設client程序覆寫了這個item並想把它寫回到memcached中。能夠通過cas命令把那個唯一標識一起發送給memcached。假設該item存放在memcached中的唯一標識與您提供的一致，寫操作將會成功。假設還有一個進程在這期間也改動了這個item，那么該item存放在memcached中的唯一標識將會改變，寫操作就會
失敗。
具體了解Memcached的內存分配機制：
http://cjjwzs.javaeye.com/blog/762453