1. 程式人生 > >Memcache儲存大資料的問題(大於1m)

Memcache儲存大資料的問題(大於1m)

轉自:https://blog.csdn.net/u011386690/article/details/9316545 感謝原作者

 

 Memcached儲存單個item最大資料是在1MB內,如果資料超過1M,存取set和get是都是返回false,而且引起效能的問題。

我們之前對排行榜的資料進行快取,由於排行榜在我們所有sql select查詢裡面佔了30%,而且我們排行榜每小時更新一次,所以必須對資料做快取。為了清除快取方便,把所有的使用者的資料放在同一key中,由於memcached:set的時候沒有壓縮資料。在測試服測試的時候,沒發現問題,當上線的時候,結果發現,線上人數剛剛490人的時候,伺服器load average飄到7.9。然後我們去掉快取,一下子就下降到0.59。


所以Memcahce不適合快取大資料,超過1MB的資料,可以考慮在客戶端壓縮或拆分到多個key中。大的資料在進行load和uppack到記憶體的時候需要花很長時間,從而降低伺服器的效能。

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的資料,但是經過客戶端壓縮資料後,只要小於1M的資料都能儲存成功。

memcached相關知識:

1、memcached的基本設定 
1)啟動Memcache的伺服器端 
# /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是監聽的伺服器IP地址,如果有多個地址的話,我這裡指定了伺服器的IP地址192.168.0.200, 
-p是設定Memcache監聽的埠,我這裡設定了12000,最好是1024以上的埠, 
-c選項是最大執行的併發連線數,預設是1024,我這裡設定了256,按照你伺服器的負載量來設定, 
-P是設定儲存Memcache的pid檔案,我這裡是儲存在 /tmp/memcached.pid,

2)如果要結束Memcache程序,執行:

# kill `cat /tmp/memcached.pid`

雜湊演算法將任意長度的二進位制值對映為固定長度的較小二進位制值,這個小的二進位制值稱為雜湊值。雜湊值是一段資料唯一且極其緊湊的數值表示形式。如果雜湊一段明文而且哪怕只更改該

段落的一個字母,隨後的雜湊都將產生不同的值。要找到雜湊為同一個值的兩個不同的輸入,在計算上是不可能的。

2、適用memcached的業務場景?

1)如果網站包含了訪問量很大的動態網頁,因而資料庫的負載將會很高。由於大部分資料庫請求都是讀操作,那麼memcached可以顯著地減小資料庫負載。

2)如果資料庫伺服器的負載比較低但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服務

     如果應用本身託管在低端的虛擬私有伺服器上,像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是memcached伺服器端內部的限制。如果使用的Memcached客戶端支援"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、什麼是二進位制協議,是否需要關注?

二進位制協議嘗試為端提供一個更有效的、可靠的協議,減少客戶端/伺服器端因處理協議而產生的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當前值的唯一標識。如果客戶端程式覆寫了這個item並想把它寫回到memcached中,可以通過cas命令把那個唯一標識一起傳送給memcached。如果該item存放在memcached中的唯一標識與您提供的一致,寫操作將會成功。如果另一個程序在這期間也修改了這個item,那麼該item存放在memcached中的唯一標識將會改變,寫操作就會失敗。
--------------------- 
作者:fredy_yang 
來源:CSDN 
原文:https://blog.csdn.net/u011386690/article/details/9316545 
版權宣告:本文為博主原創文章,轉載請附上博文連結!