目前 Facebook 用了 800 台,共 28TB 的 memcached server:「Scaling memcached at Facebook」。計算上應該是有很多 64GB RAM 這個等級的 server 在撐。(2007 年五月的時候是 200 台 16GB 的機器:Re: Largest production memcached install?)
Facebook 使用的量夠大,所以花了不少時間找出 memcached 本身的問題。他們把修正後的版本放到 Github 上,這陣子應該會慢慢 back-port 回官方版本:「Facebooks modifications to memcached for I/O, CPU and memcory scaling」。
首先是 memcached 用 TCP,但前端的 Web Server (Apache) 有很多連線,這對 memcached 本身不是問題 (因為使用 libevent),但每個連線都會消耗一些記憶體 (像是 buffer),所以 Facebook 改寫 buffer 的部份,以 buffer pool 的方式共用資源。("we implemented a per-thread shared connection buffer pool for TCP and UDP sockets")
另外是開發 UDP memcached Protocol,用這個方式提高 TCP Protocol 本身的效率問題。但實際在使用時發現 Linux kernel 對於 UDP socket 的 locking mechanism 並不好。治本的方法是修正 Linux kernel 的 UDP socket locking mechanism,不過他們認為工程太浩大,所以改為使用多個 UDP socket 解決這個問題。
在 appliction level 則是儘量使用 multi-get,盡可能減少封包數量以及延遲時間 (latency)。
再來是因為封包數量太多,Linux kernel 對於網路處理預設的方式會有過多的 interrupt,所以這部份要調整成 polling-based algorithm (並且配合 interrupt 避免過高的 latency),以此提高 Network I/O 效率。
接著發現 memcached 的統計分析是一個 global lock,在 8-core 上會有 20%~30% 的 CPU resource 卡在 lock 上,所以這部份被改寫成 per-thread stat,並且在真正需要產生資料時再加總,避免了 lock 的問題。最後則是發現 Linux kernel 處理 UDP transmit 的 queue 本身也有 lock 問題,這部份的改善則是透過 batch processing 減少 locking 問題,降低 locking 的需求。
在這些修正後,單台 server 可以從原先的 20k UDP requests/sec 拉到 50k UDP requests/sec。
請問, 我看了幾篇文章, 裏面有提到 32bit OS 的限制, memory 只能用到 2G, 是否我裝了 win2008 server 64bit 版本, 就可以使用超過 2G 的 memory?
ps. 我目前安裝的是 1.2.6 的 32bit memcacheD