加载中…
正文 字体大小:

kmemcache:一种更高性能的memcached替代解决方案

(2013-06-16 16:47:15)
分类: kmemcache

kmemcache

1. 我们做了什么

Memcached是著名的高性能分布式内存对象缓存服务系统,被国内外众多公司应用于动态Web以减轻数据库负载。

Kmemcache是搜狐基础架构部的同学将目前最新稳定版本的memcached v1.4.15移植到linux内核的一个开源项目(主页:https://github.com/jgli/kmemcache),旨在充分利用硬件资源,提供并发量更高、响应更快的缓存服务系统。

目前除了SASL(一种用来扩充C/S模式验证能力的机制)功能外,kmemcache实现了memcached所有主要功能,包括完整的二进制、文本协议,基于tcpudpunix 域的通信协议,slab分配器动态均衡、hash表扩容等。所有操作、编程接口保持与memcached一致,兼容目前所有的客户端编程接口,可以说现有的所有使用memcached的客户端,不加修改就可以轻易的使用kmemcache服务,或者可以轻易的就能将kmemcache服务器动态添加到memcached集群中。

在测试环境中,kmemcachememcached响应时间快了30%,网卡吞吐量提高了50%,但是中断数和cpu负载都有明显的降低,说明kmemcache对硬件的利用率更高。在测试过程中遇到irq balance问题,即所有或绝大部分网卡中断、软中断都集中在一个cpu上处理,此时kmemcache受到较大影响,性能退化到与memcached接近。这类问题在memcached Google Groups上有相关的讨论,如:

Ø  Memcached make many SI (Software Interrupts) https://groups.google.com/forum/?fromgroups&hl=en-GB#!searchin/memcached/interrupt/memcached/OLLqktIN7Y4/WpP8r-EWV_UJ

Ø  Multi-threading and cpu affinity https://groups.google.com/forum/?fromgroups&hl=en-GB#!searchin/memcached/interrupt/memcached/TLNkSE0yg4k/tNibh0LfSQkJ

当然这是所有网络服务器在大并发下都会遇到的一个典型问题,解决方案在上面两个问题中已有讨论。由于kmemcache在实现中充分利用了多核的特性,所以在实际部署中建议考虑到大并发下的irq balance问题。

下面是一个测试案例,客户端与服务器采用直连的方式,尽量减少路由等外在的网络影响因素,服务器采用系统默认配置,即没有考虑irq balance等问题。

Ø  server:

Intel(R) Xeon(R) CPU E5410@2.33GHz, 8cpu, mem 8G

Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12)        rhel 2.6.32-279.el6.x86_64

Ø  client:

Intel(R) Xeon(R) CPU X5650@2.67GHz, 24cpu, mem 45G

Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)

rhel 2.6.32-279.9.1.el6.x86_64

Ø  配置编译选项,去掉memcached v1.4.15 sasl服务以及debug信息,编译安装。

Ø  启动cache服务, kmemcache端口号为11213memcached11212,都指定最大3500M缓存:

$ insmod kmemcache.ko

$ umemcached -p 11213 -d -m 3500 –c 25000

$ memcached -p 11212 -d -m 3500 -t 8 –c 25000

Ø  客户安装libmemcached v1.0.17,进行如下测试,模拟并发量在1K20K间:

$ memslap --concurrency=1000 --servers=10.1.80.52:11212 --test=get

Ø  测试结果如下(conn:并发量,单位千;recv:网卡收包速率,单位兆;send:网卡发包速率,单位兆;time:响应时间,单位秒):

kmemcache:一种更高性能的memcached替代解决方案

 

图表 1(kmemcache & memcached 性能对比)

2.   我们是怎么做的

Errata Security公司的CEO Robert Graham,在Shmoocon 2013大会上谈到千万级并发问题:C10M Defending The Internet At Scale(在CSDN上有中文译本:http://www.csdn.net/article/2013-05-16/2815317-The-Secret-to-10M-Concurrent-Connections)。与大部分人反应一样,我们开始也认为Robert是无稽之谈,然而随着kmemcache优化的深入,我们越来越赞同Robert的观点,甚至Robert为我们的优化提供了理论依据。至于Robert的主要观点“关键要理解内核不是解决办法,内核是问题所在”与kmemcache运行在内核态,不过是看待同一个问题的两种不同技术实现,殊途同归。下面结合这篇文章,分析kmemcache中的部分实现。

2.1   低效的epoll机制

epollLinux下多路复用IO接口select/poll的增强版本,它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率,可显著提高应用程序的性能,如MemcachedNginxLighthttp等服务器在linux平台下就是采用epoll机制实现同步非阻塞的高效应用。

epoll机制需要linux内核的支持,其中最重要的就是要理解epoll是一种事件驱动机制吗?回答这个问题需要看站在哪个层面:对用户空间的同步非阻塞应用程序来说,无疑是一种事件驱动的高效机制,同windows平台的交互式应用程序的消息驱动模型并无本质的区别;从epoll的实现层面看,用户空间的这种使用其实是基于消息或信号量的一种主动机制,数据与处理是两个独立的过程,即数据过程是当有实际数据读写请求到来时,标识相应状态标志位后结束,处理过程则是在之后主动轮询到这个状态,进行相应处理。

所以,epoll的不足在于将数据过程与处理过程分离,这种分离在SMP系统上还很有可能处于不同的cpu上。导致这种情况的根本原因在于内核的分层结构,使其不能较好的支持多核编程技术。

2.2   内核是问题所在

Linux在设计之初就采用了Unix的思想,Robert谈到,Unix的设计初衷并不是一般的服务器操作系统,而是电话网络的控制系统。由于是实际传送数据的电话网络,所以在控制层和数据层之间有明确的界限。问题是我们现在根本不应该使用Unix服务器作为数据层的一部分。正如设计只运行一个应用程序的服务器内核,肯定和设计多用户的服务器内核是不同的。

内核做了太多的事情,数据层与控制层的界限具体体现在各个子系统的抽象接口中,而子系统的抽象导致的结果是不能充分发挥硬件多核的特性。如下图,从内核中数据包的处理路径看出,cpu都有各自的队列与网卡进行数据包的交互,这主要体现了数据过程的逻辑,而以后的处理过程(如epoll之后的操作),是否处于相同的cpu处理队列中呢?目前的内核并没有作出这种保证。

kmemcache:一种更高性能的memcached替代解决方案

图表 2 network L1/L2

2.3   Kmemcache实现机制

如何改变你的软件,使其规模化?许多只提升硬件性能去支撑项目扩展的经验都是值得借鉴的,然而我们提升了数倍的硬件性能,却换不来相同倍数的程序性能,我们需要知道性能的实际情况。

要达到到更高的水平,需要解决的问题如下:

  Ø  数据包的可扩展性

  Ø  多核的可扩展性

  Ø  内存的可扩展性

数据包的可扩展性:数据包的问题是它们需经内核的处理。网络堆栈复杂缓慢,数据包最好直接到达应用程序,而非经过操作系统处理之后,但是编写自己的网络堆栈代码是件困难的事情,kmemcache利用插口层的回调函数,实现了基于packet的线程调度机制。

多核的可扩展性:采用多核处理器系统,kmemcache利用内核中的工作队列机制,实现处理线程与cpu的绑定,对于3.0之后的内核,需要编写自己的内核线程处理代码。

内存的可扩展性:如大内存页技术等,kmemcache并没有过多的考虑内存方面的问题,目前主要提供了一个buffer 管理器,大部分内存操作,如slab,读写缓冲区都在buffer基础上管理。


欢迎大家与我进行使用或技术上的沟通,QQ群:169986537,MAIL: byjgli@gmail.com

0

阅读 评论 收藏 转载 喜欢 打印举报
  • 评论加载中,请稍候...
发评论

       

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 不良信息反馈 电话:4006900000 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有