MySQL · 源码分析 · 内存分配机制

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 前言内存资源由操作系统管理,分配与回收操作可能会执行系统调用(以 malloc 算法为例,较大的内存空间分配接口是 mmap, 而较小的空间 free 之后并不归还给操作系统 ),频繁的系统调用必然会降低系统性能,但是可以最大限度的把使用完毕的内存让给其它进程使用,相反长时间占有内存资源可以减少系统调用次数,但是内存资源不足会导致操作系统频繁换页,降低服务器的整体性能。数据库是使用内存的“大

前言

内存资源由操作系统管理,分配与回收操作可能会执行系统调用(以 malloc 算法为例,较大的内存空间分配接口是 mmap, 而较小的空间 free 之后并不归还给操作系统 ),频繁的系统调用必然会降低系统性能,但是可以最大限度的把使用完毕的内存让给其它进程使用,相反长时间占有内存资源可以减少系统调用次数,但是内存资源不足会导致操作系统频繁换页,降低服务器的整体性能。

数据库是使用内存的“大户”,合理的内存分配机制就尤为重要,上一期月报介绍了 PostgreSQL 的内存上下文,本文将介绍在 MySQL 中又是怎么管理内存的。

基础接口封装

MySQL 在基本的内存操作接口上面封装了一层,增加了控制参数 my_flags

void *my_malloc(size_t size, myf my_flags)
void *my_realloc(void *oldpoint, size_t size, myf my_flags)
void my_free(void *ptr)

my_flags 的值目前有:

MY_FAE 		/* Fatal if any error */
MY_WME			/* Write message on error */
MY_ZEROFILL	/* Fill array with zero */

MY_FAE 表示内存分配失败就退出整个进程,MY_WME 表示内存分配失败是否需要记录到日志中,MY_ZEROFILL 表示分配内存后初始化为0。

MEM_ROOT

基本结构

在 MySQL 的 Server 层中广泛使用 MEM_ROOT 结构来管理内存,避免频繁调用封装的基础接口,也可以统一分配和管理,防止发生内存泄漏。不同的 MEM_ROOT 之间互相没有影响,不像 PG 中不同的内存上下文之间还有关联。这可能得益于 MySQL Server 层是面向对象的代码,MEM_ROOT 作为类中的一个成员变量,伴随着对象的整个生命周期。比较典型的类有: THD,String, TABLE, TABLE_SHARE, Query_arena, st_transactions 等。

MEM_ROOT 分配内存的单元是 Block,使用 USED_MEM 结构体来描述。结构比较简单,Block 之间相互连接形成内存块链表,left 和 size 表示对应 Block 还有多少可分配的空间和总的空间大小。

typedef struct st_used_mem
{				   /* struct for once_alloc (block) */
  struct st_used_mem *next;	   /* Next block in use */
  unsigned int	left;		   /* memory left in block  */
  unsigned int	size;		   /* size of block */
} USED_MEM;

而 MEM_ROOT 结构体负责管理 Block 链表 :

typedef struct st_mem_root
{
  USED_MEM *free;                  /* blocks with free memory in it */
  USED_MEM *used;                  /* blocks almost without free memory */
  USED_MEM *pre_alloc;             /* preallocated block */
  /* if block have less memory it will be put in 'used' list */
  size_t min_malloc;
  size_t block_size;               /* initial block size */
  unsigned int block_num;          /* allocated blocks counter */
  /* 
     first free block in queue test counter (if it exceed 
     MAX_BLOCK_USAGE_BEFORE_DROP block will be dropped in 'used' list)
  */
  unsigned int first_block_usage;

  void (*error_handler)(void);
} MEM_ROOT;

整体结构就是两个 Block 链表,free 链表管理所有的仍然存在可分配空间的 Block,used 链表管理已经没有可分配空间的所有 Block。pre_alloc 类似于 PG 内存上下文中的 keeper,在初始化 MEM_ROOT 的时候就可以预分配一个 Block 放到 free 链表中,当 free 整个 MEM_ROOT 的时候可以通过参数控制,选择保留 pre_alloc 指向的 Block。min_malloc 控制一个 Block 剩余空间还有多少的时候从 free 链表移除,加入到 used 链表中。block_size 表示初始化 Block 的大小。block_num 表示 MEM_ROOT 管理的 Block 数量。first_block_usage 表示 free 链表中第一个 Block 不满足申请空间大小的次数,是一个调优的参数。err_handler 是错误处理函数。

分配流程

使用 MEM_ROOT 首先需要初始化,调用 init_alloc_root, 通过参数可以控制初始化的 Block 大小和 pre_alloc_size 的大小。其中比较有意思的点是 min_block_size 直接指定一个值 32,个人觉得不太灵活,对于小内存的申请可能会有比较大的内存碎片。另一个是 block_num 初始化为 4,这个和决定新分配的 Block 大小策略有关。

void init_alloc_root(MEM_ROOT *mem_root, size_t block_size,
                     size_t pre_alloc_size __attribute__((unused)))
{
  mem_root->free= mem_root->used= mem_root->pre_alloc= 0;
  mem_root->min_malloc= 32;
  mem_root->block_size= block_size - ALLOC_ROOT_MIN_BLOCK_SIZE;
  mem_root->error_handler= 0;
  mem_root->block_num= 4;                       /* We shift this with >>2 */
  mem_root->first_block_usage= 0;

  if (pre_alloc_size)
  {
    if ((mem_root->free= mem_root->pre_alloc=
         (USED_MEM*) my_malloc(pre_alloc_size+ ALIGN_SIZE(sizeof(USED_MEM)),
                               MYF(0))))
    {
      mem_root->free->size= pre_alloc_size+ALIGN_SIZE(sizeof(USED_MEM));
      mem_root->free->left= pre_alloc_size;
      mem_root->free->next= 0;
      rds_update_query_size(mem_root, mem_root->free->size, 0);
    }
  }
  DBUG_VOID_RETURN;
}

初始化完成就可以调用 alloc_root 进行内存申请,整个分配流程并不复杂,代码也不算长,为了方便阅读贴出来,也可以略过直接看分析。

void *alloc_root( MEM_ROOT *mem_root, size_t length )
{
    size_t        get_size, block_size;
    uchar        * point;
    reg1 USED_MEM    *next = 0;
    reg2 USED_MEM    **prev;

    length = ALIGN_SIZE( length );
    if ( (*(prev = &mem_root->free) ) != NULL ) // 判断 free 链表是否为空
    {
        if ( (*prev)->left < length &&
             mem_root->first_block_usage++ >= ALLOC_MAX_BLOCK_USAGE_BEFORE_DROP &&
             (*prev)->left < ALLOC_MAX_BLOCK_TO_DROP ) // 优化策略
        {
            next                = *prev;
            *prev                = next->next; /* Remove block from list */
            next->next            = mem_root->used;
            mem_root->used            = next;
            mem_root->first_block_usage    = 0;
        }
        // 找到一个空闲空间大于申请内存空间的 Block 
        for ( next = *prev; next && next->left < length; next = next->next )
            prev = &next->next;
    }
    if ( !next ) // free 链表为空,或者没有满足可分配条件 Block
    {       /* Time to alloc new block */
        block_size    = mem_root->block_size * (mem_root->block_num >> 2);
        get_size    = length + ALIGN_SIZE( sizeof(USED_MEM) );
        get_size    = MY_MAX( get_size, block_size );

        if ( !(next = (USED_MEM *) my_malloc( get_size, MYF( MY_WME | ME_FATALERROR ) ) ) )
        {
            if ( mem_root->error_handler )
                (*mem_root->error_handler)();
            DBUG_RETURN( (void *) 0 );                              /* purecov: inspected */
        }
        mem_root->block_num++;
        next->next    = *prev;
        next->size    = get_size;
        next->left    = get_size - ALIGN_SIZE( sizeof(USED_MEM) );    
        *prev        = next;		// 新申请的 Block 放到 free 链表尾部
    }

    point = (uchar *) ( (char *) next + (next->size - next->left) );
    if ( (next->left -= length) < mem_root->min_malloc )  // 分配完毕后,Block 是否还能在 free 链表中继续分配
    {                                                                       /* Full block */
        *prev                = next->next;                   /* Remove block from list */
        next->next            = mem_root->used;
        mem_root->used            = next;
        mem_root->first_block_usage    = 0;
    }
}

首先判断 free 链表是否为空,如果不为空,按逻辑应该遍历整个链表,找到一个空闲空间足够大的 Block,但是看代码是先执行了一个判断语句,这其实是一个空间换时间的优化策略,因为free 链表大多数情况下都是不为空的,几乎每次分配都需要从 free 链表的第一个 Block 开始判断,我们当然希望第一个 Block 可以立刻满足要求,不需要再扫描 free 链表,所以根据调用端的申请趋势,设置两个变量:ALLOC_MAX_BLOCK_USAGE_BEFORE_DROP 和 ALLOC_MAX_BLOCK_TO_DROP,当 free 链表的第一个 Block 申请次数超过 ALLOC_MAX_BLOCK_USAGE_BEFORE_DROP 而且剩余的空闲空间小于 ALLOC_MAX_BLOCK_TO_DROP,就把这个 Block 放到 used 链表里,因为它已经一段时间无法满足调用端的需求了。

如果在 free 链表中没有找到合适的 Block,就需要调用基础接口申请一块新的内存空间,新的内存空间大小当然至少要满足这次申请的大小,同时预估的新 Block 大小是 : mem_root->block_size * (mem_root->block_num >> 2) 也就是初始化的 Block 大小乘以当前 Block 数量的 1/4,所以初始化 MEM_ROOT 的 block_num 至少是 4。

找到合适的 Block 之后定位到可用空间的位置就行了,返回之前最后需要判断 Block 分配之后是否需要移动到 used 链表。

归还内存空间的接口有两个:mark_blocks_free(MEM_ROOT *root)free_root(MEN_ROOT *root,myf MyFlags) ,可以看到两个函数的参数不像基础封装的接口,没有直接传需要归还空间的指针,传入的是 MEM_ROOT 结构体指针,说明对于 MEM_ROOT 分配的内存空间,是统一归还的。mark_blocks_free 不真正的归还 Block,而是放到 free 链表中标记可用。free_root 真正归还空间给操作系统,MyFlages 可以控制是否和标记删除的函数行为一样,也可以控制 pre_alloc 指向的 Block 是否归还。

总结

  • 从空间利用率上来讲,MEM_ROOT 的内存管理方式在每个 Block 上连续分配,内部碎片基本在每个 Block 的尾部,由 min_malloc 成员变量和参数 ALLOC_MAX_BLOCK_USAGE_BEFORE_DROP,ALLOC_MAX_BLOCK_TO_DROP 共同决定和控制,但是 min_malloc 的值是在代码中写死的,有点不够灵活,可以考虑写成可配置的,同时如果写超过申请长度的空间,就很有可能会覆盖后面的数据,比较危险。但相比 PG 的内存上下文,空间利用率肯定是会高很多的。
  • 从时间利用率上来讲,不提供 free 一个 Block 的操作,基本上一整个 MEM_ROOT 使用完毕才会全部归还给操作系统,可见 MySQL 在内存上面还是比较“贪婪”的。
  • 从使用方式上来讲,因为 MySQL 拥有多个存储引擎,引擎之上的 Server 层是面向对象的 C++ 代码,MEM_ROOT 常常作为对象中的一个成员变量,在对象的生命周期内分配内存空间,在对象析构的时候回收,引擎的内存申请使用封装的基本接口。相比之下 MySQL 的使用方式更加多元,PG 的统一性和整体性更好。
相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助 &nbsp; &nbsp; 相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
弹性计算 资源调度 Kubernetes
数仓系列 | 深入解读 Flink 资源管理机制
文章主要从基本概念、当前机制与策略、未来发展方向等三个方面帮助开发者深入理解 Flink 的资源管理机制。
数仓系列 | 深入解读 Flink 资源管理机制
|
1月前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
1月前
|
人工智能 分布式计算 数据管理
阿里云位居 IDC MarketScape 中国实时湖仓评估领导者类别
国际数据公司( IDC )首次发布了《IDC MarketScape: 中国实时湖仓市场 2024 年厂商评估》,阿里云在首次报告发布即位居领导者类别。
|
1月前
|
SQL 分布式计算 数据挖掘
加速数据分析:阿里云Hologres在实时数仓中的应用实践
【10月更文挑战第9天】随着大数据技术的发展,企业对于数据处理和分析的需求日益增长。特别是在面对海量数据时,如何快速、准确地进行数据查询和分析成为了关键问题。阿里云Hologres作为一个高性能的实时交互式分析服务,为解决这些问题提供了强大的支持。本文将深入探讨Hologres的特点及其在实时数仓中的应用,并通过具体的代码示例来展示其实际应用。
164 0
|
4月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18509 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
2月前
|
存储 机器学习/深度学习 监控
阿里云 Hologres OLAP 解决方案评测
随着大数据时代的到来,企业面临着海量数据的挑战,如何高效地进行数据分析和决策变得尤为重要。阿里云推出的 Hologres OLAP(在线分析处理)解决方案,旨在为用户提供快速、高效的数据分析能力。本文将深入探讨 Hologres OLAP 的特点、优势以及应用场景,并针对方案的技术细节、部署指导、代码示例和数据分析需求进行评测。
127 7
|
2月前
|
运维 数据挖掘 OLAP
阿里云Hologres:一站式轻量级OLAP分析平台的全面评测
在数据驱动决策的今天,企业对高效、灵活的数据分析平台的需求日益增长。阿里云的Hologres,作为一站式实时数仓引擎,提供了强大的OLAP(在线分析处理)分析能力。本文将对Hologres进行深入评测,探讨其在多源集成、性能、易用性以及成本效益方面的表现。
128 7
|
3月前
|
分布式计算 安全 OLAP
7倍性能提升|阿里云AnalyticDB Spark向量化能力解析
AnalyticDB Spark如何通过向量化引擎提升性能?
|
3月前
|
人工智能 分布式计算 数据管理
阿里云位居 IDC MarketScape 中国实时湖仓评估领导者类别
国际数据公司(IDC)首度发布《IDC MarketScape: 中国实时湖仓市场 2024 年厂商评估》,阿里云荣登领导者地位。报告评估了13家厂商,涵盖互联网、云服务及大数据领域。阿里云凭借其在实时湖仓领域的创新能力,特别是Apache Paimon及与Flink的集成,实现了高效流批处理和AI增强功能,为企业提供了一体化的湖仓解决方案,支持多种数据管理和AI应用场景,展现出了强大的市场领导力和技术实力。
135 8

相关产品

  • 云数据库 RDS MySQL 版