腾讯云布道师：一次性能峰值提升10W的DB调优之旅(4)

发布时间：2021-01-07 14:34 所属栏目：53 来源：网络整理

导读：MySQL read view 问题改进为了解决 read view 问题,5.6 做了以下几件事情：将 5.5 的 trx_list 拆分为 ro_trx_list rw_trx_list,由于只读事务不会对数据进行修改,所以在创建视图的同时就只需要扫描 rw_trx_list

MySQL read view 问题改进

为了解决 read view 问题,5.6 做了以下几件事情：

将 5.5 的 trx_list 拆分为 ro_trx_list & rw_trx_list,由于只读事务不会对数据进行修改,所以在创建视图的同时就只需要扫描 rw_trx_list 即可；
auto-commit-non-locking-ro transactions?的特殊优化；
添加语法 START TRANSACTION READ ONLY 用于声名事务是只读事务；

经过上面的修改,似乎解决了 read view 的问题,但实际却不然,因为他只是解决了事务链表的长度,创建时遍历&内存消耗的开销是没有解决的,并且使用上述特性需要修改应用程序,这一点是比较困难的,5.7为了彻底的解决 read view 的性能问题,做了以下事情：

Refactor the MVCC code
Reuse read views for AC-NL-RO selects
Use a pool of read views
Add MVCC class
Use a trx_id to trx_t* map
Keep the active trx_id_ts in a vector.
Pre-allocate a small cache of record and table locks
Avoid extra work when a transaction is tagged as read-only (during commit).
General code cleanup
Get rid of trx_sys_t::ro_trx_list. Adding and removing a transaction from the ro_trx_list ???is very costly.

经过了上面的代码重构,5.7 中很少看到 trx_sys->mutex 的性能瓶颈,有想更详细了解的同学可以看一下这些内容：

mutex" width="560" height="249" />

为了解决 Read view 的性能问题,简单的说 CDB 内核团队对于Read view 主要做了以下事情：

经过上面的修改彻底的解决了 read_view 的性能问题,在经历了大量稳定性测试 & 性能测试后,目前灰度发布中.

鉴于当前存在的问题,为了解决客户的燃眉之急,决定上一个新版本,和客户联系后,可以重启实例,然后进行了替换操作,替换后的性能效果如下,可以看到 cpu 使用率、load、thread running 降低的同时 QPS + TPS 性能上升,至此问题真正觉得问题应该解决了,余下的就是等客户的反馈了.

将监控数据入库,查看峰值 & 当时的负载情况,详情如下：

真的完美了吗,其实不是这样的,我们还有很多的事情要做,因为在解决问题的过程中,我们通过 pstack & pt-pmp 抓到了很多有用的信息,有一些是暂时没有解决的,如：

由于时间问题我们暂时将遇到的问题一一记下,一个一个解决,我们相信 CDB 的内核会越来越强大,在提升性能的同时也不断的提升稳定性,我们一步一步踏在当下,努力变得更好!

文章出处：DBAplus社群(订阅号ID：dbaplus)

（编辑：ASP站长网）