文档章节

关于Memcached客户端CPU过高问题的排查

我爱睡觉
 我爱睡觉
发布于 2017/06/24 16:07
字数 2215
阅读 3
收藏 0

转自:http://database.51cto.com/art/201008/219948.htm

公司网站使用了Memcached来做分布式缓存,最近有人反映Memcached客户端占用CPU过高,怀疑是第三方客户端性能不佳,进而怀疑是文本协议的问题,要求部门自己开发Memcached的客户端,使其支持二进制协议。因为重新开发客户端工作量比较大,同时在日常开发中,没有听说过Memcached客户端遇到瓶颈。因此对此问题进行了排查。结果发现主要是由于客户端反序列化,类设计不合理造成的。把排查过程分享下,希望对其他人有所帮助。 

首先想到是:Memcached服务器端内存占满,在清理内存中,造成客户端socket连接不上,不断发生异常。随上服务器查看了Memcached的内存占用率,连接数等,发现利用率均很低。暂时先排除服务器端问题。 

其次想到可能是第三方在使用socket连接池时,造成资源没有关闭,或者死锁。随对第三方客户端代码粗略读了一遍,并搜索相关文档。未发现异常代码。暂时先排除第三方客户端问题。 

最后想到会不会是开发人员在代码编写中出现了问题。随对反映问题的两个产品进行了排查。发现了以下代码。


  
  1. static Serializer ser = new Serializer(typeof(List<UserModule>)); 
  2. //using JsonExSerializer;  
  3. public static List<UserModule> GetAllUserModule(int userId)  
  4. {  
  5.     string cache = CacheManager.Current.Get<string>(GetCacheKey(userId));  
  6.     if (!string.IsNullOrEmpty(cache))  
  7.     {  
  8.         return ser.Deserialize(cache) as List<UserModule>;  
  9.     }  
  10.     else 
  11.     {  
  12.         return null;  
  13.     }  
  14. }  
  15.  
  16. public static List<UserModule> SetAllUserModule(int userId, List<UserModule> modules)  
  17. {  
  18.     if (modules != null)  
  19.     {  
  20.         string cache = ser.Serialize(modules);  
  21.         CacheManager.Current.Add(GetCacheKey(userId), cache);  
  22.     }  
  23.     else 
  24.     {  
  25.         CacheManager.Current.Remove(GetCacheKey(userId));  
  26.     }  
  27.     return modules;  

代码片段2  


  
  1. /// <summary>  
  2. /// 聊天室房间  
  3. /// </summary>  
  4. [Serializable]  
  5. public class Room  
  6. {  
  7.     //房间有观看人员数据  
  8.     List<Viewer> _viewers = null;  
  9.     List<string> _blackips = null;  
  10.     List<Viewer> _blackviewers = null;  
  11.     List<Notice> _notice = null;  
  12.     List<Speaker > _speakers = null;  
  13.     List<Content> _content = null;  
  14.  
  15.  
  16.     /// <summary>  
  17.     /// 添加新聊天者  
  18.     /// </summary>  
  19.     /// <returns>返回新添加的聊天人员</returns>  
  20.     public Viewer AddViewer()  
  21.     {  
  22.         Viewer vi = new Viewer();  
  23.         //MaxViewerID += 1;  
  24.           
  25.         //int id = MaxViewerID;   
  26.         int id = GetViewerID();   
  27.         vi.Name = GetViewerName("游客" + id);  
  28.         //vi.IP = System.Web.HttpContext.Current.Request.UserHostAddress;  
  29.         vi.IP = "127.0.0.1";  
  30.         vi.ViewID = id;  
  31.         Viewers.Add(vi);  
  32.         return vi;   
  33.     }  
  34.  
  35. /// <summary>  
  36.     /// 添加聊天内容  
  37.     /// </summary>  
  38.     /// <param name="content">聊天的内容</param>  
  39.     /// <param name="viewid">发言人的id</param>  
  40.     /// <returns>返回新添加的对象</returns>  
  41.     public Content AddContent(string content, int viewid)  
  42.     {  
  43.         MaxContentID += 1;  
  44.         Content con = new Content(DateTime.Now, content, viewid, MaxContentID);  
  45.         Contents.Add(con);  
  46.         return con;  
  47.     }  
  48.     ......  

调用代码为:


  
  1. Room room = LiveSys.Get(key);  
  2. lock (room)  
  3. {  
  4.     if (room.MaxContentID == 0)  
  5.     {  
  6.         //ChatContentOp cpo = new ChatContentOp();  
  7.         //room.MaxContentID = cpo.GetMaxContentID();  
  8.  
  9.         room.MaxContentID = 300;  
  10.     }  
  11.     int viewerID = 123124123;  
  12.     room.AddContent(chatContent, viewerID);  
  13.     //判断内容是否大于100条。如果大于100条,删除最近的100条以外的数据。  
  14.     System.IO.File.AppendAllText(@"d:\haha.txt""最大数值:" + 
  15. room.LimitContentCount + "###############聊天记录数:" + room.Contents.Count + "\r\n");  
  16.     if (room.Contents.Count > room.LimitContentCount)  
  17.     {  
  18.         room.Contents.RemoveRange(0, room.Contents.Count - room.LimitContentCount);  
  19.     }  
  20. }  
  21. LiveSys.Set(key, room); 

代码1存在的问题是:

Cache存储的参数类型为object,没有必要先进行一次序列化,然后再进行存储。而序列化是很消耗CPU的。

代码2问题:

代码2实现的是一个在线聊天室,聊天室本身含有访客,发言等内容。在发言时,对聊天室内容进行判断,只显示最近30条。新进来访客直接加到访客别表中。表面上是没什么问题的。但是细想之下有两个问题:

聊天室类设计的比较复杂,每次从Memcached服务端取得数据后,都要进行类型转换。

没有访客清理机制。随着访客的不断进入,对象的体积会不断增大。

对存疑部分编写了代码进行测试。测试结果果然如推测所想。测试结果如下:

场景

写入

读取

大小

(单位)

CPU

次数

时间

平均

次数

时间

平均

本地缓存

10000

0.03125

0

10000

0

0

1k

0

MemClient

10000

19.2656

0.001926

10000

22.75

0.002275

1k

Json1k

1000

2.8437

0.002843

1000

5.375

0.005375

1k

Json8k

1000

3.8593

0.003859

1000

29.0312

0.029031

8k

直播1000人次

1000

38.9375

0.038937

1000

50k

直播8000人次

100

18.25

0.1825

100

350k

500k

100

7.375

0.07375

100

7.09375

0.070937

500k

场景

写入

读取

大小

(单位)

CPU

次数

时间

平均

次数

时间

平均

本地缓存

10000

0.03125

3.125E-06

10000

0.015625

1.5625E-06

1k

0

MemClient

10000

19.78125

0.001978

10000

21.953125

0.002195

1k

 

Json1k

1000

2.03125

0.002031

1000

6.078125

0.006078

1k

 

Json8k

1000

2.765625

0.002765

1000

55.375

0.055375

8k

 

直播1000人次

1000

38.53125

0.038531

1000

   

50k

 

直播8000人次

100

17.96875

0.179687

1000

   

350k

 

500k

100

7.5

0.075

100

6.5625

0.065625

500k

 

场景

写入

读取

大小

(单位)

CPU

次数

时间

平均

次数

时间

平均

本地缓存

10000

0.015625

1.5625E-06

10000

0.015625

1.5625E-06

1k

0

MemClient

10000

18.015625

0.001801

10000

25.96875

0.002596

1k

6%

Json1k

1000

1.15625

0.001156

1000

3.078125

0.003078

1k

40%

Json8k

1000

1.859375

0.001859

1000

32.484375

0.032484

8k

50%

直播1000人次

1000

45.046875

0.045046

1000

   

50k

30-40%

直播8000人次

100

31.703125

0.317031

100

   

350k

50%

500k

100

7.0625

0.070625

100

6.421875

0.064218

500k

6%

直播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类型,取值时再反序列化回来。

嗯,还有这事?

开发人员说了相关代码。 


  
  1. interface IUser  
  2. {  
  3.     String UserId{ getset;}  
  4.     String UserName{ getset;}  
  5. }  
  6.  
  7. [Serializable]  
  8. class UserInfo : IUser  
  9. {  
  10.     String UserId{ getset;}  
  11.     String UserName{ getset;}  
  12. }  
  13. [Serializable]  
  14. class Game  
  15. {  
  16.     IUser User{ getset;}  
  17.     String UserName{ getset;}  

他说:Game对象在直接使用MemcachedClient时,是不能被二进制序列化的,因为其User属性类型为IUser,为一个接口。因此想了一个解决方法,即先将Game对象进行 json序列化将其变为字符串,然后将字符串存储到Memcached 

原来是这样。

接着又查看了MemcachedClient源代码,其需要将对象进行二进制序列化,然后进行存储。接口属性不能被序列化,遂又对序列化问题进行了测试(见附件)。测试结果显示上述代码直接进行二进制序列化是可以的,同时直接使用第三方客户端也是可以可行的。 

问题出在哪?难道是没有加[Serializable]

一查果然:一个Serializable引发的血案。。。

记得有人说过,慎用分布式,能不用尽量不用。

一方面在性能上确实下降很多,分布式存储主要性能消耗在以下几个方面:协议解析,Socket连接,数据传输,序列化/类型转换。

一方面在使用场景和类设计上要求也更加严格。个人认为Memcached是不太适合存储特别大的文件的。虽然有人说网上已经有用来存储视频的。

还有几个问题希望知道的朋友回答下:

有没有.Net方面的Memcached客户端支持二进制协议和一致性的?

测试中发现,当Memcached设置缓存过小时(例如64M),当其内存使用已经到62M时,再进行存储,新存储的内容再取出来就是空值,不知道是什么原因。

本文转载自:http://blog.csdn.net/rachel_luo/article/details/9001216

我爱睡觉
粉丝 3
博文 2120
码字总数 0
作品 0
南昌
私信 提问
memcached 分布式实现原理

本文作者:伯乐在线 -Float_Lu 。未经作者许可,禁止转载! 欢迎加入伯乐在线专栏作者。 摘要 在高并发环境下,大量的读、写请求涌向数据库,此时磁盘IO将成为瓶颈,从而导致过高的响应延迟,...

伯乐在线
2016/05/20
0
0
无法连接windows实例的问题排查

无论何种原因导致无法远程连接实例,先尝试用阿里云提供的远程连接功能进行连接,然后再按原因分类进行故障排查。 1. 客户端本地网络异常 故障现象:用户无法登录外网。 可能原因:网卡驱动未...

lulullll
2018/11/10
0
0
该如何提高解决问题的能力?

@囚兔 你好,想跟你请教个问题:我在开发过程中,遇到一些生僻的问题,不知道该怎么解决,都是网上有网友分享了答案,我照做,如果没人分享,我就不知道该怎么办了,就是缺少独立寻找问题原因...

mksegs
2017/07/20
89
1
memcached分布式实现原理

摘要 在高并发环境下,大量的读、写请求涌向数据库,此时磁盘IO将成为瓶颈,从而导致过高的响应延迟,因此缓存应运而生。无论是单机缓存还是分布式缓存都有其适应场景和优缺点,当今存在的缓...

Float_Luuu
2016/05/08
3.3K
0
【重要安全预警】Memcached被利用UDP反射攻击漏洞预警

本周,阿里云安全中心监测到互联网上存在利用Memcached服务漏洞进行的恶意攻击。如果客户默认开放UDP协议且未做访问控制,在运行Memcached服务时可能会被黑客利用,导致出方向的带宽消耗或C...

Mr_zebra
2018/03/06
98
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 我,小小编辑,食人族酋长

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @宇辰OSC :分享娃娃的单曲《飘洋过海来看你》: #今日歌曲推荐# 《飘洋过海来看你》- 娃娃 手机党少年们想听歌,请使劲儿戳(这里) @宇辰OSC...

小小编辑
今天
725
10
MongoDB系列-- SpringBoot 中对 MongoDB 的 基本操作

SpringBoot 中对 MongoDB 的 基本操作 Database 库的创建 首先 在MongoDB 操作客户端 Robo 3T 中 创建数据库: 增加用户User: 创建 Collections 集合(类似mysql 中的 表): 后面我们大部分都...

TcWong
今天
40
0
spring cloud

一、从面试题入手 1.1、什么事微服务 1.2、微服务之间如何独立通讯的 1.3、springCloud和Dubbo有哪些区别 1.通信机制:DUbbo基于RPC远程过程调用;微服务cloud基于http restFUL API 1.4、spr...

榴莲黑芝麻糊
今天
26
0
Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
75
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
74
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部