数据结构论坛

注册

 

发新话题 回复该主题

MYSQL深潜剖析Performanc [复制链接]

1#
一引言

MYSQLPrformancschma(PFS)是mysql提供的强大的性能监控诊断工具,提供了一种能够在运行时检查srvr内部执行情况的特方法。PFS通过监视srvr内部已注册的事件来收集信息,一个事件理论上可以是srvr内部任何一个执行行为或资源占用,比如一个函数调用、一个系统调用wait、SQL查询中的解析或排序状态,或者是内存资源占用等。

PFS将采集到的性能数据存储在prformanc_schma存储引擎中,prformanc_schma存储引擎是一个内存表引擎,也就是所有收集的诊断信息都会保存在内存中。诊断信息的收集和存储都会带来一定的额外开销,为了尽可能小的影响业务,PFS的性能和内存管理也显得非常重要了。

本文主要是通过对PFS引擎的内存管理的源码的阅读,解读PFS内存分配及释放原理,深入剖析其中存在的一些问题,以及一些改进思路。本文源代码分析基于Mysql-8.0.24版本。

二内存管理模型

PFS内存管理有几个关键特点:

内存分配以Pag为单位,一个Pag内可以存储多条cord系统启动时预先分配部分pags,运行期间根据需要动态增长,但pag是只增不回收的模式cord的申请和释放都是无锁的

1核心数据结构

PFS_buffr_scalabl_containr是PFS内存管理的核心数据结构,整体结构如下图:

Containr中包含多个pag,每个pag都有固定个数的cords,每个cord对应一个事件对象,比如PFS_thad。每个pag中的cords数量是固定不变的,但pag个数会随着负载增加而增长。

2Allocat时Pag选择策略

PFS_buffr_scalabl_containr是PFS内存管理的核心数据结构

涉及内存分配的关键数据结构如下:

PFS_PAGE_SIZE//每个pag的大小,global_thad_containr中默认为PFS_PAGE_COUNT//pag的最大个数,global_thad_containr中默认为classPFS_buffr_scalabl_containr{PFS_cachlin_atomic_siz_tm_monotonic;//单调递增的原子变量,用于无锁选择pagPFS_cachlin_atomic_siz_tm_max_pag_indx;//当前已分配的最大pagindxsiz_tm_max_pag_count;//最大pag个数,超过后将不再分配新pagstd::atomicarray_typ*m_pags[PFS_PAGE_COUNT];//pag数组nativ_mutx_tm_critical_sction;//创建新pag时需要的一把锁}

首先m_pags是一个数组,每个pag都可能有f的cords,也有可能整个pag都是busy的,Mysql采用了比较简单的策略,轮训挨个尝试每个pag是否有空闲,直到分配成功。如果轮训所有pags依然没有分配成功,这个时候就会创建新的pag来扩充,直到达到pag数的上限。

轮训并不是每次都是从第1个pag开始寻找,而是使用原子变量m_monotonic记录的位置开始查找,m_monotonic在每次在pag中分配失败是加1。

核心简化代码如下:

valu_typ*allocat(pfs_dirty_stat*dirty_stat){curnt_pag_count=m_max_pag_indx.m_siz_t.load();monotonic=m_monotonic.m_siz_t.load();monotonic_max=monotonic+curnt_pag_count;whil(monotonicmonotonic_max){indx=monotonic%curnt_pag_count;array=m_pags[indx].load();pfs=array-allocat(dirty_stat);if(pfs){//分配成功返回turnpfs;}ls{//分配失败,尝试下一个pag,//因为m_monotonic是并发累加的,这里有可能本地monotonic变量并不是线性递增的,有可能是从1直接变为3或更大,//所以当前whil循环并不是严格轮训所有pag,很大可能是跳着尝试,换者说这里并发访问下大家一起轮训所有的pag。//这个算法其实是有些问题的,会导致某些pag被跳过忽略,从而加剧扩容新pag的几率,后面会详细分析。monotonic=m_monotonic.m_siz_t++;}}//轮训所有Pag后没有分配成功,如果没有达到上限的话,开始扩容pagwhil(curnt_pag_countm_max_pag_count){//因为是并发访问,为了避免同时去创建新pag,这里有一个把同步锁,也是整个PFS内存分配唯一的锁nativ_mutx_lock(m_critical_sction);//拿锁成功,如果array已经不为null,说明已经被其它线程创建成功array=m_pags[curnt_pag_count].load();if(array==nullptr){//抢到了创建pag的责任m_allocator-alloc_array(array);m_pags[curnt_pag_count].sto(array);++m_max_pag_indx.m_siz_t;}nativ_mutx_unlock(m_critical_sction);//在新的pag中再次尝试分配pfs=array-allocat(dirty_stat);if(pfs){//分配成功并返回turnpfs;}//分配失败,继续尝试创建新的pag直到上限}}

我们再详细分析下轮训pag策略的问题,因为m_momotonic原子变量的累加是并发的,会导致一些pag被跳过轮训它,从而加剧了扩容新pag的几率。

举一个极端一些的例子,比较容易说明问题,假设当前一共有4个pag,第1、4个pag已满无可用cord,第2、3个pag有可用cord。

当同时来了4个线程并发Allocat请求,同时拿到了的m_monotonic=0.

monotonic=m_monotonic.m_siz_t.load();

这个时候所有线程尝试从第1个pag分配cord都会失败(因为第1个pag是无可用cord),然后累加去尝试下一个pag

monotonic=m_monotonic.m_siz_t++;

这个时候问题就来了,因为原子变量++是返回最新的值,4个线程++成功是有先后顺序的,第1个++的线程后monotonic值为2,第2个++的线程为3,以次类推。这样就看到第3、4个线程跳过了pag2和pag3,导致3、4线程会轮训结束失败进入到创建新pag的流程里,但这个时候pag2和pag3里是有空闲cord可以使用的。

虽然上述例子比较极端,但在Mysql并发访问中,同时申请PFS内存导致跳过一部分pag的情况应该还是非常容易出现的。

3Pag内Rcord选择策略

PFS_buffr_dfault_array是每个Pag维护一组cords的管理类。

关键数据结构如下:

classPFS_buffr_dfault_array{PFS_cachlin_atomic_siz_tm_monotonic;//单调递增原子变量,用来选择f的cordsiz_tm_max;//cord的最大个数T*m_ptr;//cord对应的PFS对象,比如PFS_thad}

每个Pag其实就是一个定长的数组,每个cord对象有3个状态FREE,DIRTY,ALLOCATED,FREE表示空闲cord可以使用,ALLOCATED是已分配成功的,DIRTY是一个中间状态,表示已被占用但还没分配成功。

Rcord的选择本质就是轮训查找并抢占状态为f的cord的过程。

核心简化代码如下:

valu_typ*allocat(pfs_dirty_stat*dirty_stat){//从m_monotonic记录的位置开始尝试轮序查找monotonic=m_monotonic.m_siz_t++;monotonic_max=monotonic+m_max;whil(monotonicmonotonic_max){indx=monotonic%m_max;pfs=m_ptr+indx;//m_lock是pfs_lock结构,f/dirty/allocatd三状态是由这个数据结构来维护的//后面会详细介绍它如何实现原子状态迁移的if(pfs-m_lock.f_to_dirty(dirty_stat)){turnpfs;}//当前cord不为f,原子变量++尝试下一个monotonic=m_monotonic.m_siz_t++;}}

选择cord的主体主体流程和选择pag基本相似,不同的是pag内cord数量是固定不变的,所以没有扩容的逻辑。

当然选择策略相同,也会有同样的问题,这里的m_monotonic原子变量++是多线程并发的,同样如果并发大的场景下会有cord被跳过选择了,这样导致pag内部即便有f的cord也可能没有被选中。

所以也就是pag选择即便是没有被跳过,pag内的cord也有几率被跳过而选不中,雪上加霜,更加加剧了内存的增长。

4pfs_lock

每个cord都有一个pfs_lock,来维护它在pag中的分配状态(f/dirty/allocatd),以及vrsion信息。

关键数据结构:

structpfs_lock{std::atomicm_vrsion_stat;}

pfs_lock使用1个32位无符号整型来保存vrsion+stat信息,格式如下:

stat低2位字节表示分配状态。

statPFS_LOCK_FREE=0x00statPFS_LOCK_DIRTY=0x01statPFS_LOCK_ALLOCATED=0x11

vrsion

初始vrsion为0,每分配成功一次加1,vrsion就能表示该cord被分配成功的次数主要看一下状态迁移代码:

//下面3个宏主要就是用来位操作的,方便操作stat或vrsion#dfinVERSION_MASK0xFFFFFFFC#dfinSTATE_MASK0x#dfinVERSION_INC4boolf_to_dirty(pfs_dirty_stat*copy_ptr){uint32old_val=m_vrsion_stat.load();//判断当前stat是否为FREE,如果不是,直接返回失败if((old_valSTATE_MASK)!=PFS_LOCK_FREE){turnfals;}uint32nw_val=(old_valVERSION_MASK)+PFS_LOCK_DIRTY;//当前stat为f,尝试将stat修改为dirty,atomic_

分享 转发
TOP
发新话题 回复该主题