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

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

导读：经过上面参数的调整,DB 已经不是性能的瓶颈,应用的吞吐量由之前的 1100 - 1400+,但是离 2000 的吞吐量还比较远,瓶颈出现在了应用端,为了增加吞吐量,客户又增加了几台客户端机器,连接数也由之前的 900+ 上升到 1000+

经过上面参数的调整,DB 已经不是性能的瓶颈,应用的吞吐量由之前的 1100 -> 1400+,但是离 2000 的吞吐量还比较远,瓶颈出现在了应用端,为了增加吞吐量,客户又增加了几台客户端机器,连接数也由之前的 900+ 上升到 1000+,此时发现 DB 虽然能够响应,但偶尔会出现 thread running 飙高的情况,具体运行状态如下,其中 mysql_com_tps = (mysql_com_insert + mysql_com_update + mysql_com_delete)：

查找问题原因

Thread running 的偶尔飙升引起了我的注意,说明内部必然有冲突,随着压力和并发量的不断增大,应用可能会受到类似之前的影响,因此很有必要查看其中的原因并尽最大的努力解决之.通过仔细观察 thread running & mysql com 信息,当 thread running 较高 & com 信息较低的时候,执行了 pt-pmp -p {pid of mysqld},抓到了以下信息：

从上面的现场信息不难看出有很大一部分线程是在执行 read_view 的相关操作中被阻塞着了,那么什么是 read view,它的作用是什么,为什么会有大量的线程执行这个操作的时候被阻塞呢?

什么是 read view

read view 又称读视图,用于存储事务创建时的活跃事务集合.当事务创建时,线程会对 trx_sys 上全局锁,然后遍历当前活跃事务列表,将当前活跃事务的ID存储在数组中的同时,记录最大事务 low_limit_id &　最小事务 high_limit_id & 最小序列化事务 low_limit_no.

read view 的作用是什么

InnoDB record 格式包含 {记录头,主建,Trx_id,roll_ptr,extra_column} 等信息.

当事务执行时,凡是大于low_limit_id 的数据对于事务是不可见的,凡是事务小于 high_limit_id 的数据都是可见的,事务 ID 是 read_view 数组中的某一个时也是不可见的,Purge thread 在执行 Purge 操作时,凡是小于 low_limit_no 的数据,都是可以被 Purge 的,read view 是 MySQL MVCC 实现的基础.

为什么会有大量的线程阻塞

事务创建时的步骤如下：

对 trx_sys->mutex 全局上锁；
顺序扫描 trx_sys->rw_trx_list,对 read_view 中的元素分配内存并进行赋值,主要包括活跃事务ID的集合的创建,low_limit_id,high_limit_id,low_limit_no 等；
将该 read_view 添加到有序列表 trx_sys->view_list中；
释放?trx_sys->mutex 锁；

由于read_view 的创建和销毁都需要获取 trx_sys->mutex,当并发量很大的时候,事务链表会比较长,又由于遍历本身也是一个费时的工作,所以此处便成为了瓶颈,既然我们遇到了这个问题,那么社区应该也有类似的问题.

read view 问题解决过程

首先,我们看一下bug#49169(https://bugs.mysql.com/bug.php?id=49169),read_view_open_now is inefficient with many concurrent sessions,即当并发量很大时 read_view_open_now 效率低下的问题,问题的原因主要有以下几个：

整个创建过程一直持有 trx_sys->mutex 锁；
read_view?的内存在每次创建中被分配,事务提交后被释放；
需要遍历 trx_sys->trx_list (5.5) 或 trx_sys->rw_list (5.6)；
并发较大,活跃事务链表过长时,会在 trx_sys->mutex 上有较大的消耗；

该 bug 从 MySQL 5.1 的时候被 mrak 大神提出以来,一直到 MySQL 5.7 才被官方完整的解决,其中的解决过程也挺曲折的,另外 Percona 在 5.5 的时候就也推出了解决问题的办法,实现也相对简单好多,但没有 MySQL 5.7 方法的彻底,咱们分别看一下这两种解决方法以及 CDB 内核在这方面的改动.

Percona read view 问题改进

Percona 为了解决上述描述的问题,对trx_sys做了以下修改：

在 trx_sys下维护一个全局的事务ID的有序集合,事务的创建 & 销毁的同时将事务的 ID 从这个集合中移除；
在 trx_sys下维护一个有序的已分配序列号的事务列表,已记录拥有最小序列号的事务,供 purge 时使用；
减少不必要的内存分配,为每一个 trx_t 缓存一个 read_view,read_view 数组的大小根据创建时的活跃全局事务 ID 集合做必要的调整；

做了上面的调整后,事务在创建过程中则不需要遍历 trx_sys->trx_list(version 5.5),直接使用 memcpy 即可获得活跃事务的ID,并且缓存的使用也大大减少了内存的不必要分配；

更详细的信息及源码可以参考 Alexey (sysbench owner,MySQL 另一大神)提交的代码,commit message 详情如下：

（编辑：ASP站长网）