开发者社区> db匠> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

MongoDB · 特性分析 · 网络性能优化

简介: 从 C10K 说起 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解。『C10K』概念最早由 Dan Kegel 发布于其个人站点,即出自其经典的《The C10K problem》一文[1]。 于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP。这些操作系统提供的功能就是为了解决C1
+关注继续查看

从 C10K 说起

对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解。『C10K』概念最早由 Dan Kegel 发布于其个人站点,即出自其经典的《The C10K problem》一文[1]。

于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP。这些操作系统提供的功能就是为了解决C10K问题。

常用网络模型

方案 名称 接受连接 网络 IO 计算任务
1 thread-per-connection 1个线程 N个线程 在网络线程执行
2 单线程 Reactor 1个线程 在连接线程执行 在连接线程执行
3 Reactor + 线程池 1个线程 在连接线程执行 C2线程
4 one loop per thread 1个线程 C1线程 在网络线程执行
5 one loop per thread + 线程池 1个线程 C1线程 C2线程

注:N 表示并发连接数,C1和 C2 与连接数无关,与 CPU 数组相关的常数。

当然,还有一些用户态的解决方案,例如Intel DPDK。来自KVM核心的研发团队推出了一款数据库叫做ScyllaDB[2],其使用了SeaStar网络框架[3],SeaStar是目前可用性最好的用户态网络编程框架,在基于DPDK实现了socket语义之后,进一步提供了线程乃至协程的语义封装,便于上层应用使用。

看看利用Seastar加速的http和memcached并发可以达到多少级别,并且随着cpu核数增加线性增长,就能感受用户态网络的巨大威力了。
httpd
memcached

各个方案中各有优缺点,要根据不同的业务场景因地制宜,包括但不限于:CPU 密集型,IO 密集型,长连接,短连接,同步,异步,硬件特性。

官方 IO 模型分析

MongoDB 现在使用的同步 IO 模型,如图:

m2

由主线程进行 accept 连接,然后针对每一个连接创建一个线程进行处理,「thread per connection」这种模型

  • 其一,不适合短连接服务,创建/删除线程的开销是巨大的,体现在创建线程时间和至少1MB 内存的使用。
  • 其二,伸缩性受到线程数的限制,200+线程数的调度对 OS 也是不小的负担。另外随着线程数的增加, 由于 mongo 本身业务的特性,对数据处理的并发度并不高,DB锁和全局的原子操作造成的 context-switch 也是急剧上升,性能反而下降,频繁的线程切换对于 cache 也不友好。

下面一张图可以看出各级缓存之间的响应时间差距,以及内存访问到底有多慢!
cache

改进方案

基于上述思考和 MongoDB 的业务特性:

  • 部分命令可能阻塞
  • 长连接
  • 高并发需求
  • 通用性

我们选型方案5,「one loop per thread」加上线程池,利用分而治之的思想。
有一个 main reactor 负责 accept 连接,然后把连接挂载某个sub reactor(采用round-robin的方式来选择sub reactor),这样该连接的所用操作都在那个sub reactor所处的线程池中完成。如图:

m1.png

同步模型到异步模型的转变,也引入了一些问题需要我们解决:

  • 非 pingpong 模型,乱序问题;
  • 请求优先级反转;
  • 线程池忙等;
  • cache miss 是否减少。

以上问题我们将在下文中一一展开。

网络框架对比

libevent: libevent 就如名字所言,是一个异步事件框架。从 OS 那里获得事件, 然后派发。派发机制就是“回调函数”。异步异步,归根结底就是处理从操作系统获得的事件。

libev: 就设计哲学来说,libev的诞生,是为了修复libevent设计上的一些错误决策。例如,全局变量的使用。

libuv: 开发node的过程中需要一个跨平台的事件库,他们首选了libev,但又要支持Windows,故重新封装了一套,*nix下用libev实现,Windows下用IOCP实现。

boost.asio: 跨平台的 Proactor 模型实现,目前已经进入 C++17 的标准提案

libco: libco是微信后台大规模使用的c/c++网络协程库。

调研与验证

asio 在 MongoDB 上使用越来越多[4],而且满足我们跨平台的需求。如下在调研了性能后,我们还是选择了 asio

使用 boost.asio 编写 echo 客户端,服务端, 验证 asio 网络框架的极限性能,指导我们对 MongoDB 的性能优化。

echo 客户端的代码: https://gist.github.com/yjhjstz/ee1820efe0ff0c1ed83a6eb4649c7985

模型1- echo service 端:
https://gist.github.com/yjhjstz/4eceba80ecd328a87784a0fe0b602d6c

    // 省略 ....
    echo_server();
    boost::thread_group tg;
    for (int i = 0; i < thread_count; ++i)
        tg.create_thread([]{ ios.run(); });
    tg.join_all();
    return 0;

一个 IO 线程 + 线程池的模型,但锁的竞争被放大,QPS 在35W左右。

模型2 —- echo service 端 :
https://gist.github.com/yjhjstz/a9eb964fd20d6e5c186d7a2ba3921c8f#file-server-cpp
多个 IO 线程的模型,基本没有锁竞争,QPS 在90W+。

代码实现

修改原则:

  • 尽量增加接口,尽量不改动原有接口
  • 利用重载,实现自己的类,做到代码开关可控。

实现略,开源 patch 准备中,请期待。

回答四个问题

同步模型到异步模型的转变,一些问题需要我们解决:

问题1的解决得益于 asio 提供的 Preactor 编程模型,async_* 的驱动在每个 IO 线程(或者线程池),但单个命令不返回客户端,下个数据包就不会被触发响应。

请求优先级反转的问题具体场景可以是心跳包或者其他。我们隔离了单独的IO 线程去处理和管理此类连接。

针对问题3,线程池忙等,我们实现了动态可伸缩的线程池,通过配置线程池中线程的最小值和最大值实现动态申请和回收线程。

问题4,我们使用 perf stat 来验证:

// 未优化前
[jianghua.yjh@r101072xxx.sqa.zmf /home/jianghua.yjh]
$sudo perf stat -e cache-references,cache-misses -p 21782

 Performance counter stats for process id '21782':

    31,807,891,996 cache-references
     1,515,770,600 cache-misses              #    4.765 % of all cache refs

     126.836238857 seconds time elapsed

// 优化后
[jianghua.yjh@r101072xxx.sqa.zmf /home/jianghua.yjh]
$sudo perf stat -e cache-references,cache-misses -p 20047
 Performance counter stats for process id '20047':

    35,495,507,358 cache-references
     1,344,188,577 cache-misses              #    3.787 % of all cache refs

      99.501870882 seconds time elapsed

cache-miss 在优化后降了1个百分点。进一步的,我们发现 update_curr 相比占比上升,也就是花在线程调度上的工作导致了部分的 cache-miss, 锁的 lock, unlock 排在了前面(如图),
perf-cache.png

锁这块我们还在努力研究优化中~~

性能测试报告

测试环境 (standalone)

  1. Linux, Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz, SSD
  2. 136 部署修改过的 YCSB 测试工具, 137 部署 mongod, 针对大量不同的连接数进行测试,场景 workloada。
  3. 随着连接数的增加,刚开始qps会不断成倍增长,当server资源已经达到上限时,继续增加连接数,qps会降低,同时平均的延时也在增加;
    因测试存在一定的偶然性,测试结果里个别数据项可能跟总的趋势不匹配,但经多次测试验证,总的趋势是类似。
  4. 请求延时分布统计了平均延时、95%的请求延时(95%的请求延时小于该值)、99%请求延时。

workloada QPS(50% read + 50% update )

workloada_ops_merge.png

Latency update (同步模型)

workloada_update_latency.png

Latency update (异步模型)

workloada_update_latency.png

总结

  • 在高并发场景下,排队控制导致同步模型平均update延时超过1S,降级到不可用的状态。
  • 异步模型性能保持稳定,优化后我们获得了60%+的 QPS 收益。
  • 调优过程中使用到了很多性能剖析利器 ,可以参考博文:Linux常用性能调优工具索引

参考

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
MongoDB-SQL优化
本文主要讲述了MongoDB的SQL优化相关的几个知识点:1)查询优化器原理;2)执行计划解析;3)性能排查手段;4)读写优化
3900 0
MongoDB · 特性分析 · 索引原理
为什么需要索引? 当你抱怨MongoDB集合查询效率低的时候,可能你就需要考虑使用索引了,为了方便后续介绍,先科普下MongoDB里的索引机制(同样适用于其他的数据库比如mysql)。 mongo-9552:PRIMARY&gt; db.person.find() { "_id" : ObjectId("571b5da31b0d530a03b3ce82"), "name" : "jack",
1486 0
【云栖干货】MongoDB疑难杂症分析及优化
本文主要介绍阿里云 MongoDB 数据库上客户遇到的问题,及相应的解决方案。
9067 0
MongoDB运行状态、性能监控,分析
mongostat详解 mongostat是mongdb自带的状态检测工具,在命令行下使用。
805 0
MongoDB 2.4企业版分析
MongoDB v2.4版于3月19日发布,它引入了内置的文本搜索功能,以及基于哈希的分片和众所期盼的安全特性。同时,10gen公司发布了MongoDB的企业版,它在开源版的基础上增加了安全和监控的特性,易于与其它企业软件相集成。
592 0
+关注
db匠
rds内核团队秘密研发的全自动卖萌机. 追加特效: 发数据库内核月报. 月报传送: http://mysql.taobao.org/monthly/
496
文章
0
问答
来源圈子
更多
让用户数据永远在线,让数据无缝的自由流动
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载