MySQL buffer pool初始化内存分配

之前一直理解的是buffer pool在启动时候就被分配好,今天有同事问到这个问题,跟着代码看了下。

buf_pool_init

|–>buf_pool_init_instance

|–>buf_chunk_init

|–>os_mem_alloc_large

ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,

MAP_PRIVATE | OS_MAP_ANON, -1, 0);

调用mmap之前TOP出来的VIRT虚拟内存为135M,调用之后VIRT值为2714M,而实际的物理内存RES才不到100M

也就是说mmap并没有分配物理内存。

实际上这里使用mmap时限了匿名的存储区域映射,那么mmap和直接malloc有什么区别呢?

做个简单的实验

1.

#include <stdio.h>

#include <malloc.h>

#include <fcntl.h>

#include <sys/mman.h>

int main(int argc, char *argv[])

{

printf(“alloc=====\n”);

char *ptr = malloc(2693120000); //2.5G

sleep(60);

free(ptr);

printf(“=====finish\n”);

return 0;

}

2.

将内存分配修改为:

void* ptr= mmap(0, 2693120000, PROT_READ | PROT_WRITE,

MAP_ANON | MAP_SHARED, -1 , 0);

看起来不管是malloc,还是mmap,都没有分配实际的物理地址,仅仅是分配了虚拟内存。

那么什么时候才会分配内存呢?mysqld拿到的只是映射自物理内存的一块虚拟内存,只有在应用程序真正使用到内存时才会去映射到实际的物理内存。这些工作都是由内核来完成的

时间: 2024-12-11 11:36:03

MySQL buffer pool初始化内存分配的相关文章

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

前言 内存资源由操作系统管理,分配与回收操作可能会执行系统调用(以 malloc 算法为例,较大的内存空间分配接口是 mmap, 而较小的空间 free 之后并不归还给操作系统 ),频繁的系统调用必然会降低系统性能,但是可以最大限度的把使用完毕的内存让给其它进程使用,相反长时间占有内存资源可以减少系统调用次数,但是内存资源不足会导致操作系统频繁换页,降低服务器的整体性能. 数据库是使用内存的"大户",合理的内存分配机制就尤为重要,上一期月报介绍了 PostgreSQL 的内存上下文,本

MySQL · 引擎特性 · InnoDB Buffer Pool

前言 用户对数据库的最基本要求就是能高效的读取和存储数据,但是读写数据都涉及到与低速的设备交互,为了弥补两者之间的速度差异,所有数据库都有缓存池,用来管理相应的数据页,提高数据库的效率,当然也因为引入了这一中间层,数据库对内存的管理变得相对比较复杂.本文主要分析MySQL Buffer Pool的相关技术以及实现原理,源码基于阿里云RDS MySQL 5.6分支,其中部分特性已经开源到AliSQL.Buffer Pool相关的源代码在buf目录下,主要包括LRU List,Flu List,Do

[MySQL 源码] 从buffer pool中获取空闲block流程

当我们将一个page读入内存时,需要先为其分配一个block,从buffer pool中获取.入口函数为buf_LRU_get_free_block 之前在http://mysqllover.com/?p=303有简要介绍,这里详细看看,当然,跟最近博客的主题一样,我们还是主要针对压缩表来分析. 以下分析基于Percona Server 5.5.18 buf_LRU_get_free_block loop: 1.block = buf_LRU_get_free_only(buf_pool) 首先

[MySQL学习] 一个压缩Page从磁盘读入buffer pool的过程

以下是边看代码边记录的,从磁盘读取一个压缩Page到buffer pool的的全过程,以函数buf_page_get_gen作为入口 buf_page_get_gen 1.根据space和offset来计算请求的page是否已经读到了buffer pool中 fold = buf_page_address_fold(space, offset); block = (buf_block_t*) buf_page_hash_get_low(                           buf

MySQL内核月报 2015.02-MySQL · 性能优化· InnoDB buffer pool flush策略漫谈

背景 我们知道InnoDB使用buffer pool来缓存从磁盘读取到内存的数据页.buffer pool通常由数个内存块加上一组控制结构体对象组成.内存块的个数取决于buffer pool instance的个数,不过在5.7版本中开始默认以128M(可配置)的chunk单位分配内存块,这样做的目的是为了支持buffer pool的在线动态调整大小. Buffer pool的每个内存块通过mmap的方式分配内存,因此你会发现,在实例启动时虚存很高,而物理内存很低.这些大片的内存块又按照16KB

MySQL 5.7 对buffer pool list scan的优化

worklog: http://dev.mysql.com/worklog/task/?id=7047 原作者Innam 跳槽到twitter后 将该特性合并到webscalesql: https://github.com/webscalesql/webscalesql-5.6/commit/c834781321d97b914c3712c663bd7209175a3fe2#diff-07468177c19cc3f32d25913fe731f936R1814 在该worklog中,主要对LRU L

MySQL · 特性分析 · innodb buffer pool相关特性

背景 innodb buffer pool做为innodb最重要的缓存,其缓存命中率的高低会直接影响数据库的性能.因此在数据库发生变更,比如重启.主备切换实例迁移等等,innodb buffer poll 需要一段时间预热,期间数据库的性能会受到明显影响. 另外mysql 5.7以前innodb buffer pool缓存大小修改不是动态的,重启才能生效.因此innodb buffer pool的预热和innodb buffer pool大小的动态修改,对性能要求较高的应用来说是不错的特性,下面

数据库内核月报 - 2015 / 07-MySQL · 社区动态 · MySQL内存分配支持NUMA

NUMA 问题曾经一直是困扰DBA的一个大问题,早在 2010 年, 就有人给MySQL报了Bug#57241, 指出了MySQL在x86系统下存在严重的 "swap insanity" 问题.在NUMA架构越来越普遍的今天,这个问题越来越严重. MySQL的 swap insanity 问题 有同学专门翻译了Jeremy Cole关于 "swap insanity" 问题的文章,原文看这里, 如果你没空看的话,这里简单描述一下,就是当你把主机大部分内存分配给Inn

[MySQL学习]Innodb压缩表之内存分配/回收

最近看到Yoshinori Matsunobu在官方buglist上提交的一个Bug#68077,大意是说,当使用压缩表时,在bp吃紧时,存在过度碎片合并的情况.Innodb压缩表由于存在不同的Page Size,因此使用buddy allocator的方式进行内存分配,他的内存块来自于buffer pool中. 如bug#68077所提到的,如果我们使用的全部是4kb的内存块,那么把他们合并成8k的又有什么意义呢?并且在碎片整理的过程中,函数buf_buddy_free 的效率是很低的.在之前