目前我們的非持久化緩存服務器（memcached）與持久化緩存服務器（nosql）用的都是Couchbase（前身是Membase）。
之前每次出故障時，阿里雲總是拿nosql服務器說事，因為nosql服務器的CPU占用的確不正常。
上圖是Linux中top命令運行的結果。問題表現為，Couchbase總是只用一個CPU核跑memcached進程（nosql中也用到了memcached），CPU幾乎跑滿，而nosql服務器實際有4個核。1個核累得要死，而其他3個核閑得蛋疼，這的確是不正常的情況，會造成有些情況下讀取緩存速度慢。阿里雲對它的懷疑有一定的道理。
后來，我們通過日志記錄了nosql服務器的讀取數據耗時，得到的數據是超過400ms的nosql讀取1天發生100多次，相對於每天超過100萬的讀取次數，這個問題影響不大。
但是，阿里雲還是每次拿它說事，我們都厭煩了。今天又提到了，我們實在受不了了，怎么辦？只有找出問題的真正原因，才能擺脫它。
對於Couchbase CPU占用高的問題，我們在4月份研究過，當時用的是Couchbase 2.0。我們在Couchbase官方論壇的一篇帖子（High cpu usage in memcached process (couchbase 2.0)）中知道了Couchbase 2.0存在CPU占用高的bug，但在Couchbase 2.0.1中已經修復了。於是，我們將Couchbase升級到了2.0.1，以為問題解決了。后來發現還是會出現CPU占用高的情況，以為是其他原因引起的。
今天，我們在Couchbase官方論壇（High cpu memcached process）中找到答案（6樓的回答）：
The fix caused a performance regression and was backed out at the last minute. At the time I made that comment the fix was in the 2.0.1 branch. We are fixing it for 2.0.2 though. I apologize for the misleading comment.
原來是Couchbase給大家開了一個玩笑，這個bug在2.0.1中並沒有被修復，要等到2.0.2。
好了，終於找到了問題的真正原因（nosql服務器CPU占用高的原因，不是之前故障的原因），這下清靜了，這下放心了。