MySQL innodb_buffer_pool 内存分配过程

MySQL innodb_buffer_pool是在mysqld启动时分配？操作系统如何显示

查看my.cnf中配置：innodb_buffer_pool_size = 20G，物理机实际内存32G

 

mysqld启动前后内存使用对比：

启动mysql 后，used增加了1.5G，cached增加2M

 

top查看mysqld进程

VIRT：

1.进程“需要的”内存大小，包括进程使用的库、代码、数据，以及malloc、new分配的堆空间和分配的栈空间等；

2. mysqld申请22.3G的内存，但实际只使用了1.5G，那么virt它会增长22.3G，而不是实际的1.5G使用量。

3. MySQL启动时实际只是在虚拟内存中分配了地址空间，而并没有真正的映射到物理内存上。

4.VIRT =SWAP + RES

 

Linux malloc内存分配:

1.malloc分配内存是先在虚拟内存中分配地址的，到实际使用时才真正的映射到物理内存

2. 到了MySQL真正要映射物理内存时，首先分配物理内存，此时top的res增加

3.如果物理内存不够用了，分配swap，此时性能很差，此时top的res增加

所以，如果由于机器内存使用不当，到了MySQL真正要映射物理内存时，如果物理内存（内存+swap）不足了，就会出错甚至退出。

 

结论：innodb_buffer_pool_size= 20G再mysqld启动时在虚拟内存中分配地址，在使用过程中再映射到物理内存,如果物理内存（内存+swap）不足了，就会出错甚至退出。

 

篇外：Linux下的OOM Killer：

假如一个程序A已经运行，并且分配了22G内存（机器配置是物理内存16G+SWAP 8G），但是没有真正的映射到物理内存；

这时MySQL启动，innodb_buffer_pool_size=8G，启动正常；

然后程序A开始实际分配物理内存，一下子只剩下2GSWAP内存了；

这时MYSQL也开始实际使用内存，因为只有2GSWAP，所以性能很差，再超过2G时，内存耗尽，这时OOMKiller开始杀进程，怎么杀呢，谁占用内存多杀谁，于是将进程A杀掉了，内存一下子回来了，MySQL不会退出；

但是一般系统中MySQL都是分配内存最大的，所以经常性的是MySQL被杀掉。