MySQL内存为什么不断增高，怎么让它释放

最新推荐文章于 2024-07-30 10:32:52 发布
最新推荐文章于 2024-07-30 10:32:52 发布
阅读量8.7k 收藏 9
点赞数
文章标签： 数据库 linux mysql java python
原文链接：https://mp.weixin.qq.com/s?__biz=MjM5NzAzMTY4NQ==&mid=2653938861&idx=1&sn=2de853dd9120693b85d91c78330249f2&chksm=bd3b7ec78a4cf7d1a95fe21ad7cff60d61c8f913f75269eec931c671e6959aa852d9525e8858&scene=126&&sessionid=0
版权

问题分析场景1 使用sysbench压测数据库场景2 load 一个很大事务的insert语句问题突破测试jemalloc场景1使用sysbench压测数据库场景2 load 一个很大事务的insert语句小结MySQL到底有没有释放内存？通过gdb调试结论

线上MySQL数据库发现一些实例，内存使用不断增高，并且当连接数断开后内存不会释放，最终导致的结果是被操作系统OOM

问题分析

模拟两个场景来分析此问题:

场景1 使用sysbench压测数据库

使用sysbench压测MySQL，等待连接断开后，使用top查看mysqld进程，内存使用情况。

将mysql innodb_buffer_pool设置为128M，方便观察内存增长情况。

启动MySQL后内存使用情况，大约在150M：

63059a35b9f59963d7338971558ecaec.jpeg


sysbench压测60s

sysbench --db-driver=mysql /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3320  --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --tables=16 --table_size=500000 --threads=128 --time=60 --report-interval=1 run

观察内存使用情况:

031835dfb50062304b0424b2c781ac45.jpeg



内存增长到540M左右，但是内存并没有随着sysbench连接断开而释放。

场景2 load 一个大事务的insert语句

重启MySQL观察内存使用情况, 大约占用170M：

1bef0ebeabcd4b827dc66d5b73eca004.jpeg


文件大小43M

75f094c06ebe0ea4d634fcdb9e0b78f4.jpeg


文件内容:

INSERT INTO dummy VALUES
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
(1,'This is a dummy value'),
.......

source 文件：

mysql> source test.sql

source完成后观察内存使用情况:

cf0f6cd88cb3721d8dc1f29b8c39a65e.jpeg



占用到1G，同样也是，没有随着连接断开，内存进行释放。

问题突破

通过上面两个例子，能证明MySQL连接断开后，内存没有释放。

长时间下去就会导致内存不断增高，查看bugs.mysql 发现有人提过此问题：
https://bugs.mysql.com/bug.php?id=83047 --里面有人提出load个大事务，复现此问题。

同样percona版本也有人提过:
https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1710146

在上面链接中，有人提到过使用jemalloc好像能够解决此问题。

测试jemalloc

同样是测试上面两种场景， 使用jemalloc方式如下:

yum install jemalloc
在mysqld_safe中，最前面添加如下信息:
export LD_PRELOAD="/lib64/libjemalloc.so.1"
重启启动mysql实例

使用pt工具确认是否是用你了jemalloc
pt-mysql-summary  -S /tmp/mysql-3320.sock --user root --password 123456|grep -A 5 "Memory management" 
显示如下信息，则代表使用了jemalloc

场景1使用sysbench压测数据库

启动MySQL后内存使用情况，大约在150M:

5787c294e26611ad42f9cca3be53fbd9.jpeg


sysbench压测60s

sysbench --db-driver=mysql /usr/share/sysbench/oltp_read_only.lua --mysql-host=127.0.0.1 --mysql-port=3320  --mysql-db=sbtest --mysql-user=root --mysql-password=123456 --tables=16 --table_size=500000 --threads=128 --time=60 --report-interval=1 run

观察内存使用情况:

c336fcef5ef9f59f20661352cad578ea.jpeg



压测时内存增长到550M左右，随着sysbench连接断开而释放了一部分内存， 保持在370M左右。

场景2 load 一个大事务的insert语句

重启MySQL观察内存使用情况, 大约占用150M:

77335862a2b4cc2857e6d9aee7022b36.jpeg


source 文件:

mysql> source test.sql

source完成后观察内存使用情况:

95a48a13c7cebfae2c56b3b2ff23510d.jpeg



随着SQL执行完成，内存释放到了300M。

小结

通过以上对比，可以得出，jemalloc内存分配方式，确实可以使内存快速释放给操作系统，减少系统内存使用过高而被OOM

MySQL到底有没有释放内存？

继续分析MySQL实际执行中，到底有没有主动释放内存？在哪里释放的内存？

通过gdb调试

  1. 先登录到mysql中

  2. 另外一个窗口，执行gdb attach 到mysql进程

/opt/rh/devtoolset-8/root/bin/gdb  -p  `ps -ef|grep  -w mysqld|grep -v grep | awk {'print $2'}`

  1. 设置断点

(gdb) b /mydata/Project/mysql-server/sql/sql_parse.cc:1947
(gdb) b connection_handler_per_thread.cc:321
Breakpoint 2 at 0x166ee7f: file /mydata/Project/mysql-server/sql/conn_handler/connection_handler_per_thread.cc, line 321.

  1. gdb 中执行c

(gdb) c
Continuing

  1. mysql客户端source 文件

mysql> source test.sql

此时可能需要等待一段时间，因为文件比较大，mysql client 需要进行解析文件，只要在gdb 窗口等待即可，不用执行任何命令，直到出现下面这种情况:

gdb) c
Continuing.
[Switching to Thread 0x7fea2b008700 (LWP 29406)]

Thread 28 "mysqld" hit Breakpoint 1, dispatch_command (thd=0x7fea02819000, com_data=0x7fea2b007c90, command=COM_QUERY)
    at /mydata/Project/mysql-server/sql/sql_parse.cc:1947
1947      free_root(thd->mem_root,MYF(MY_KEEP_PREALLOC));

  1. 此时就可以开始调试，查看MySQL内存使用情况:

(gdb) p thd->main_mem_root
$1 = {free = 0x7fe9c2406020, used = 0x7fe9c29b3020, pre_alloc = 0x7fea02827020, min_malloc = 32, block_size = 8160, block_num = 863,
  first_block_usage = 0, max_capacity = 0, allocated_size = 844547312, error_for_capacity_exceeded = 0 '\000', error_handler = 0x14baa8b
     <sql_alloc_error_handler()>, m_psi_key = 8}

这里看到allocated_size=844547312 大约是800M，此时mysqld进程占用内存情况:

63e2bc380a3d8cd154431b244e6dc5e0.jpeg



执行source 之前的内存使用情况+800M 约等于 目前的1.1g。
输入'n'执行下一步free_root后，在查看内存:

gdb) n
1961      thd->profiling.finish_current_query();
(gdb) p thd->main_mem_root
$2 = {free = 0x7fea02827020, used = 0x0, pre_alloc = 0x7fea02827020, min_malloc = 32, block_size = 8160, block_num = 4,
  first_block_usage = 0, max_capacity = 0, allocated_size = 8208, error_for_capacity_exceeded = 0 '\000',
  error_handler = 0x14baa8b <sql_alloc_error_handler()>, m_psi_key = 8}

此时allocated_size = 8208，也就是在MySQL层，执行完SQL后内存已经释放了，top看下操作系统情况:

8024bd6a9b23be3488d9ca59f8027354.jpeg


这里使用的是jemalloc，内存进行了释放(当前占有内存约300M)，如果是默认的glibc,则内存不会释放。
这里还分析到，内存的释放是SQL语句级别的，并不是整个事务结束后才释放，而是SQL执行完后即释放。

  1. 继续将会话退出，则会触发另外一个断点

68e8890027212cff924565c3c3a0bae0.jpeg


会话退出，会接受到COM_QUIT 命令，接着会释放整个线程的内存，这时再看下top中mysqld内存使用情况:

9bdadd345bf61d8e16fa1fa07c07f338.jpeg


会看到随着会话退出，内存又释放了40M左右，这部分内存就是mysql中缓存的source 文件大小，在SQL执行完后，会话不退出时，可以通过查看performance 表查看线程内存使用情况:

ee5b449106de81f639e52dde64d4bc92.jpeg



能看到，正好是等于文件的大小。

  1. kill 也会导致NET::buff释放
    通过测试，如果SQL执行完成，在另外一个会话Kill此线程，NET::buff也会被释放

这里的NET::buff并没有随着SQL执行完成释放，查看官方文档net_buffer_length的介绍:

1626611671f96e7497a8e495ba94faf4.jpeg



大概意思是:
每个客户端会话线程会分配两个缓冲区:连接缓冲区和结果集缓冲区,并且可以动态放大到 max_allowed_packet 系统变量指定的字节大小， 每个 SQL 语句执行完成 之后，结果集缓冲区自动缩小到 net_buffer_length 变量指定的大小。然后文档并没有提到连接缓冲区会被释放，也就是说会被一直缓存，直到连接断开。

结论

  1. mysql中会主动释放内存

  2. 释放内存是语句级别，不是会话级别

  3. NET::buff内存是需要会话退出后，内存才会释放

  4. kill也会释放会话所占有的内存

  5. jemalloc比glibc内存分配机制更好一些，能及时将内存释放给操作系统

《深入浅出MGR》视频课程

戳此小程序即可直达B站

https://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0


文章推荐：

想看更多技术好文，点个“在看”吧！

老叶茶馆_
关注
MySQL内存使用率高且不释放问题排查与总结
h363659487的博客
06-27 4536
总结一下MySQL内存使用率高且不释放的应对方法： 继续加大内存（如果参数调无可调时选择）； 修改减小innodb_buffer_pool_size参数（牺牲一定innodb性能）； 排查消耗内存的慢SQL，及时优化； 检查相关session参数是否设置合理，比如join_buffer_size、query_cache_size是否设置过大； 使用gdb回收内存碎片（生产环境谨慎操作）：gdb --batch --pid ‘pidof mysqld’--ex 'call malloc_trim(0)'；
【八股】MySQL篇
qq_44768318的博客
04-27 634
👉聚簇索引是指数据和索引一起存储，B+树的叶子节点存储了所有的行数据，有且只有一个👉二级索引是指数据和索引分开存储，B+树的叶子节点只存储数据对应的主键，一般用户自己创建的索引都是二级索引，可以有多个👉回表查询发生在使用二级索引查询的时候，找到对应的主键值再到聚簇索引中查找整行数据👉指查询使用了索引且需要返回的列在索引中能够全部找到，不需要回表查询，比如使用id聚簇索引，一次索引扫描返回行的所有数据。
MySQL占用内存资源过多的解决方法
m0_59308369的博客
09-08 7581
今天检查系统发现MySQL8持续运行内存不会释放，导致运行很慢的。
MYSQL内存请求一直不释放_MySQL内存不释放分析
weixin_33223159的博客
02-18 2959
问题分析场景1 使用sysbench压测数据库场景2 load 一个很大事务的insert语句问题突破测试jemalloc场景1使用sysbench压测数据库场景2 load 一个很大事务的insert语句小结MySQL到底有没有释放内存？通过gdb调试结论线上MySQL数据库发现一些实例，内存使用不断增高，并且当连接数断开后内存不会释放，最终导致的结果是被操作系统OOM问题分析模拟两个场景来分析...
mysql 内存一直增长（memory/sql/thd::main_mem_root）
最新发布
qq_44989936的博客
07-30 352
memory/sql/thd::main_mem_root
mysql5.7占用内存不断升高且不释放
baidu_38956956的博客
12-21 1193
解决MySQL5.7占用内存不断升高不释放
MYSQL内存请求一直不释放_记一次mysql内存占用过大-不释放问题排查
weixin_35578748的博客
02-18 3678
问题描述：mysql接线上报警，mysql所在服务器内存剩余不足，这个实例内存问题是周期性爆发的，经过监控看到内存平均2天就被用尽掉256GB。sql排查思路：服务器一、单个实例占用内存256GB，首先想到的是bufferpool，确认配置sessionshow global variables like '%innodb_buffer_pool_size%';orm30GB，内存SELECT @...
MYSQL内存请求一直不释放_MySQL内存不释放
weixin_31833039的博客
02-08 3664
欢迎进入Linux社区论坛，与200万技术人员互动交流 >>进入 连接了一下，并进行了一次查询操作 (root:NJ-245:Thu Apr 24 16:38:38 2014)[information_schema] select count(*) from CLIENT_STATISTICS; +----+ | count(*) | +----+ | 5 | +----+ 1 row...
mysql内存突然增高分析_mysql 资源占用过高分析和解决方法
weixin_29084111的博客
01-18 2886
分析和解决方案1，情况描述：网站发标后，出现卡顿，最后出错。2，问题排查：最后一个版本的更新是在两个星期前，照理来说，应该不是代码的问题。但是一时找不到问题所在，还是先对代码进行测试。使用排除法，修改数据后，在测试环境，生产环境测试，均正常。既然测试正常，那么排除代码的问题。那怀疑可能是服务器的问题，接下来查看Linux环境的运行情况。3，linux系统，命令top可以查看系统资源使用情况。最近两...
mysql 不释放内存_mysql内存不断被占用，导致每隔一个多月就自动重启，修改数据库配置后，问题解决...
weixin_36296064的博客
01-19 1014
这个月初，通过zabbix监控发现有1台mysql数据库的从库内存剩余空间不断降低。检查以往的监控历史图表，发现由于内存占用不断增大，每隔一个多月，就会因为内存严重不足，导致这台服务器的1个mysql实例(端口：3316)重启。数据库实例重启之后，内存被大量释放，但经过一个多月，又会因为不断占用的内存再次重启mysql实例。上图是这台服务器的zabbix监控图形，近半年来3次内存枯竭的时间分别是去...
Mysql索引
Mr.xing的博客
03-12 1658
普通索引 联合索引 哈希索引 B+Tree索引 全文检索
MySQL占用内存较大与CPU过高测试与解决办法
09-09
为了装mysql环境测试，装上后发现启动后MySQL占用内存了很大，达8百多兆。网上搜索了一下，得到高人指点my.ini。再也没见再详细的了..只好打开my.ini逐行的啃，虽然英文差了点，不过多少M还是看得明的
MySQL进程内存一直在涨，怎么办？
老叶茶馆
10-10 7908
*GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。老叶提醒：本文结合MySQL内存为什么不断增高，怎么让它释放 阅读，收获更多。1.问题开端2.问题分析3.原因及意见1.问题开端工程师反馈数据库服务器内存使用率高，并且之前曾触发告警，登录服务器使用top -u mysql查看进程使用内存信息：发现mysqld进程使用内存达到了61.5%，并有缓慢增长趋势。但是数据库...
MySQL服务器内存占用过高原因分析及解决思路
学亮编程手记
05-19 2699
Linux系统会积极地缓存文件系统元数据和其他读取过的数据到内存中，这部分缓存虽然可以被快速释放给其他需要的进程，但在统计内存使用时会被计入已使用的内存中，从而导致看似较高的内存占用率。: 虽然InnoDB缓冲池的大小是32GB，但是InnoDB还有其他内存使用，比如redo log buffer (: MySQL还会为线程、连接管理、解析器、优化器等保留一些内存，以及为其他内部操作分配临时内存。: 分配和释放内存的过程中可能会产生碎片，导致实际占用的虚拟内存比实际使用的内存要多。)、额外的内存池 (
Mysql启动占用内存过高解决
砷碲 - Shendi
12-08 1610
最近服务器内存不够用了，甚至还出现了内存溢出问题，导致程序宕机。但请求与用户量并没有多少，所以从各种启动的程序中想方设法的尽可能的减少其占用的内存。而在我的服务器中，Mysql服务占大头，吃了400多MB...
centos中mysql进程占用了大量内存，如何清理
记录技术上的一些解决方案
10-12 450
如果在 CentOS 中 MySQL 进程占用了大量内存，你可以采取以下一些步骤来进行清理和优化
python查看进程占用系统内存以及新增内存
柒然的博客
09-29 1055
查看内存 import psutil import os print(u'内存使用：{}M'.format(psutil.Process(os.getpid()).memory_info().rss/1024/1024)) 查看新增内存 import objgraph import gc objgraph.show_growth() gc.collect() # 回收内存 objgraph.show_growth()
记一次mysql内存占用过大-不释放问题排查
mysql_lover
11-18 8508
问题描述： 接线上报警，mysql所在服务器内存剩余不足，这个实例内存问题是周期性爆发的，通过监控看到内存平均2天就被用尽掉256GB。 排查思路： 1、单个实例占用内存256GB，首先想到的是bufferpool，确认配置 show global variables like '%innodb_buffer_pool_size%'; 30GB， SELECT @@innodb_buf...
主动 释放 mysql 内存
05-31
可以使用以下语句来主动释放 MySQL 的内存： ``` FLUSH TABLES; ``` 该语句会关闭所有打开的表并释放它们占用的内存，同时清空查询缓存和表缓存。但是需要注意的是，这可能会影响 MySQL 的性能，因为它会导致所有表都需要重新打开，而且缓存也需要重新加载。因此，应该在适当的时候使用这个语句，比如在修改表结构或者大量删除数据之后。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值