Memcache儲存大資料的問題

標籤：

      Memcache儲存大資料的問題   huangguisu

      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之內

由於記憶體 Clerk的演算法就是這種。

具體的回答：

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的記憶體 Clerk是怎樣工作的？為什麼不適用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的記憶體 Clerk是怎樣工作的？為什麼不適用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

   

Memcache儲存大資料的問題