公司網站使用了Memcached來做分布式緩存，最近有人反映Memcached客戶端占用CPU過高，懷疑是第三方客戶端性能不佳，進而懷疑是文本協議的問題，要求部門自己開發Memcached的客戶端，使其支持二進制協議。因為重新開發客戶端工作量比較大，同時在日常開發中，沒有聽說過Memcached客戶端遇到瓶頸。因此對此問題進行了排查。結果發現主要是由于客戶端反序列化，類設計不合理造成的。把排查過程分享下，希望對其他人有所幫助。 

首先想到是：Memcached服務器端內存占滿，在清理內存中，造成客戶端socket連接不上，不斷發生異常。隨上服務器查看了Memcached的內存占用率，連接數等，發現利用率均很低。暫時先排除服務器端問題。 

其次想到可能是第三方在使用socket連接池時，造成資源沒有關閉，或者死鎖。隨對第三方客戶端代碼粗略讀了一遍，并搜索相關文檔。未發現異常代碼。暫時先排除第三方客戶端問題。 

最后想到會不會是開發人員在代碼編寫中出現了問題。隨對反映問題的兩個產品進行了排查。發現了以下代碼。

static Serializer ser = new Serializer(typeof(List<UserModule>)); 
//using JsonExSerializer;  
public static List<UserModule> GetAllUserModule(int userId)  
{  
    string cache = CacheManager.Current.Get<string>(GetCacheKey(userId));  
    if (!string.IsNullOrEmpty(cache))  
    {  
        return ser.Deserialize(cache) as List<UserModule>;  
    }  
    else 
    {  
        return null;  
    }  
}  
 
public static List<UserModule> SetAllUserModule(int userId, List<UserModule> modules)  
{  
    if (modules != null)  
    {  
        string cache = ser.Serialize(modules);  
        CacheManager.Current.Add(GetCacheKey(userId), cache);  
    }  
    else 
    {  
        CacheManager.Current.Remove(GetCacheKey(userId));  
    }  
    return modules;  
} 

代碼片段2：  

/// <summary>  
/// 聊天室房間  
/// </summary>  
[Serializable]  
public class Room  
{  
    //房間有觀看人員數據  
    List<Viewer> _viewers = null;  
    List<string> _blackips = null;  
    List<Viewer> _blackviewers = null;  
    List<Notice> _notice = null;  
    List<Speaker > _speakers = null;  
    List<Content> _content = null;  
 
 
    /// <summary>  
    /// 添加新聊天者  
    /// </summary>  
    /// <returns>返回新添加的聊天人員</returns>  
    public Viewer AddViewer()  
    {  
        Viewer vi = new Viewer();  
        //MaxViewerID += 1;  
          
        //int id = MaxViewerID;   
        int id = GetViewerID();   
        vi.Name = GetViewerName("游客" + id);  
        //vi.IP = System.Web.HttpContext.Current.Request.UserHostAddress;  
        vi.IP = "127.0.0.1";  
        vi.ViewID = id;  
        Viewers.Add(vi);  
        return vi;   
    }  
 
/// <summary>  
    /// 添加聊天內容  
    /// </summary>  
    /// <param name="content">聊天的內容</param>  
    /// <param name="viewid">發言人的id</param>  
    /// <returns>返回新添加的對象</returns>  
    public Content AddContent(string content, int viewid)  
    {  
        MaxContentID += 1;  
        Content con = new Content(DateTime.Now, content, viewid, MaxContentID);  
        Contents.Add(con);  
        return con;  
    }  
    ......  
} 

調用代碼為：

Room room = LiveSys.Get(key);  
lock (room)  
{  
    if (room.MaxContentID == 0)  
    {  
        //ChatContentOp cpo = new ChatContentOp();  
        //room.MaxContentID = cpo.GetMaxContentID();  
 
        room.MaxContentID = 300;  
    }  
    int viewerID = 123124123;  
    room.AddContent(chatContent, viewerID);  
    //判斷內容是否大于100條。如果大于100條，刪除最近的100條以外的數據。  
    System.IO.File.AppendAllText(@"d:\haha.txt", "最大數值：" + 
room.LimitContentCount + "###############聊天記錄數：" + room.Contents.Count + "\r\n");  
    if (room.Contents.Count > room.LimitContentCount)  
    {  
        room.Contents.RemoveRange(0, room.Contents.Count - room.LimitContentCount);  
    }  
}  
LiveSys.Set(key, room); 

代碼1存在的問題是：

Cache存儲的參數類型為object，沒有必要先進行一次序列化，然后再進行存儲。而序列化是很消耗CPU的。

代碼2問題：

代碼2實現的是一個在線聊天室，聊天室本身含有訪客，發言等內容。在發言時，對聊天室內容進行判斷，只顯示最近30條。新進來訪客直接加到訪客別表中。表面上是沒什么問題的。但是細想之下有兩個問題：

1 聊天室類設計的比較復雜，每次從Memcached服務端取得數據后，都要進行類型轉換。

2 沒有訪客清理機制。隨著訪客的不斷進入，對象的體積會不斷增大。

對存疑部分編寫了代碼進行測試。測試結果果然如推測所想。測試結果如下：

直播1000人次（當天一共有1000人訪問，數據來源于運營檢測），留言內容為30條時，Room體積大概為：57K  

直播1000人次（當天一共有8000人訪問，數據來源于運營檢測），留言內容為30條時，Room體積大概為：350k

根據圖表可以看到以下情況：處理時間、CPU利用率和數據量大小，序列化，類復雜性都有關系。

序列化問題（類型轉換）對性能影響最為明顯（可在場景”json1k”、場景直播中看到）。在Json1k中，存儲對象和前幾個場景是相同的，處理時間也相差不大，較大區別是CPU利用率由5%左右增長到40%左右（反序列化時尤為明顯）。在場景直播系統中，不存在序列化問題，但是其對象屬性中存在”訪客”， ”繁衍”等多個復雜對象，造成其在處理時需要處理過多的類型轉換，同時其體積不斷增大。

存儲對象的大小和處理時間存在一定關系，例如場景”500k”，其處理時間增長，但是其CPU利用率并未提高，其時間增長是由于對象傳輸造成。

本地緩存在內存中進行尋址和類型轉換，涉及不到Socket連接，網絡傳輸，序列化操作，所以其處理相當快。

就測試結果看：

本地緩存性能大約是分布式緩存性能的100倍左右。而出問題的聊天室除了CPU增高以外，其性能更比分布式緩存再降低40倍（直播1000人次）到200倍（直播8000人次）。綜合來看，聊天室的分布式緩存比本地緩存降了4000倍，甚至更多。

但是，還沒有完。 

對于第二個問題，更改類設計，清楚無效訪客，即可解決。 

但是第一個問題，為什么用戶在存儲之前，先進行json序列化呢？嗯，這是一個問題。

遂問之。

答曰，有些類直接使用第三方客戶端存儲時，直接存儲報錯，所以先序列化為json類型，取值時再反序列化回來。

嗯，還有這事？

開發人員說了相關代碼。 

interface IUser  
{  
    String UserId{ get; set;}  
    String UserName{ get; set;}  
}  
 
[Serializable]  
class UserInfo : IUser  
{  
    String UserId{ get; set;}  
    String UserName{ get; set;}  
}  
[Serializable]  
class Game  
{  
    IUser User{ get; set;}  
    String UserName{ get; set;}  
} 

他說：Game對象在直接使用MemcachedClient時，是不能被二進制序列化的，因為其User屬性類型為IUser，為一個接口。因此想了一個解決方法，即先將Game對象進行 json序列化將其變為字符串，然后將字符串存儲到Memcached。 

原來是這樣。

接著又查看了MemcachedClient源代碼，其需要將對象進行二進制序列化，然后進行存儲。接口屬性不能被序列化，遂又對序列化問題進行了測試（見附件）。測試結果顯示上述代碼直接進行二進制序列化是可以的，同時直接使用第三方客戶端也是可以可行的。 

問題出在哪？難道是沒有加[Serializable]。

一查果然：一個Serializable引發的血案。。。

記得有人說過，慎用分布式，能不用盡量不用。

一方面在性能上確實下降很多，分布式存儲主要性能消耗在以下幾個方面：協議解析，Socket連接，數據傳輸，序列化/類型轉換。

一方面在使用場景和類設計上要求也更加嚴格。個人認為Memcached是不太適合存儲特別大的文件的。雖然有人說網上已經有用來存儲視頻的。

還有幾個問題希望知道的朋友回答下：

1 有沒有.Net方面的Memcached客戶端支持二進制協議和一致性的？

2 測試中發現，當Memcached設置緩存過小時（例如64M），當其內存使用已經到62M時，再進行存儲，新存儲的內容再取出來就是空值，不知道是什么原因。

原文標題：Memcached客戶端CPU過高問題的排查

鏈接：http://www.cnblogs.com/hellofox2000/archive/2010/08/17/1801329.html

【編輯推薦】

1. 分布式緩存系統Memcached入門指導
2. .NET分布式緩存之Memcached執行速度檢測
3. 從Memcached看MySQL和關系數據庫的未來
4. 分布式緩存系統Memcached簡介與實踐
5. Google App Engine的Java持久性與數據存儲