钉钉猛增40倍流量压力,阿里云的DBA们是这样应对的…

钉钉猛增40倍流量压力,阿里云的DBA们是这样应对的...

  • 2月6号钉钉上了中央电视台,钉钉CTO接受采访
钉钉猛增40倍流量压力,阿里云的DBA们是这样应对的...

4 、DB容量预估及性能分析

业务上往往通过集群的CPU情况即可大概分析出系统的水位,但是对DB而言不仅是CPU,IO,网络,SQL,锁等等,任何一个组件的瓶颈往往都会成为最终容量的瓶颈。不同的业务模型,往往瓶颈都不一样,即使都是查询量较大的业务,有些可能是cpu的瓶颈,有些可能是内存命中率不够导致的瓶颈,有些则是索引设计不合理导致的瓶颈。更复杂的部分在于,有些瓶颈往往不是线性的,可能压力提升2倍还没什么问题,硬件能力都还有富余,但是提升到3倍就直接挂了。在这种场景下我们如何比较准确的评估DB的容量呢?

以往我们都是通过经验并和业务方一起进行全链路压测进行DB容量(集群能支撑多少读写)的预估,这种方式有以下几个问题:

  • 压测数据集和数据库总量相比往往比较小,DB命中率基本100%,这对于分析有IO的业务模型存在较大误差
  • 成本较大,需要打通上下游整个链路,较多的同学参与
  • 即使全链路压测,真正压到DB端的往往也只是核心的几个接口,无法100%覆盖线上所有的接口,而很多慢SQL往往都来自这些易忽略的接口

解决这个痛点问题的方法大家其实很容易想到–只要把线上的业务流量全部采集下来回放一遍即可,但实现起来是非常复杂的。我们真正需要的其实是针对DB的一种通用的单链路压测能力,并不依赖上游业务,DB层可以自己进行流量的生成,放大或缩小,甚至将事务比例更改后再次压测的能力。

从2019年开始,在DBA和达摩院数据库实验室科学家们共同的努力下,我们开发了ClouDBench实现了上述的需求,并在此次的战役中帮助DBA进行容量的评估。

先展示下效果:

钉钉猛增40倍流量压力,阿里云的DBA们是这样应对的...

发表评论

电子邮件地址不会被公开。