mysqld进程占用内存过高怎么排查

遇到一个比较极端的案例，innodb_buffer_pool_size 值仅设置为2GB，但是mysqld进程却占用了25GB的内存。

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
45305 mysql     20   0   28.4g    25g   8400 S  48.5 81.4  64:46.82 mysqld

后面会有专门的文章介绍详细分析排查过程，这里先直接说可能的原因以及解决方案。

可能的原因

1、session（会话）级内存buffer参数设置过高，并且连接数也设置过高，例如

read_buffer_size = 64M
read_rnd_buffer_size = 32M
sort_buffer_size = 64M
join_buffer_size = 64M
tmp_table_size = 1G
max_heap_table_size = 1G
max_connections=2000

当连接数较少时，需要消耗的内存并不多。

但是当遇到突发流量时，可能并发连接数会接近打满，再加上可能有产生临时表、额外排序的低效率的SQL频繁出现，这就很容易导致内存占用快速增长。

因此建议调低session级buffer参数值，并有效控制并发连接数，下面是一个比较通用的设置值参考：

read_buffer_size = 4M
read_rnd_buffer_size = 4M
sort_buffer_size = 4M
join_buffer_size = 4M
tmp_table_size = 32M
max_heap_table_size = 32M
max_connections = 512

2、PFS中开启过多检测指标，造成内存消耗过大。

在上面也提到过，全部开启PFS后，可能需要大约1GB内存。不过在高并发并伴随频繁低效SQL的情况下，可能需要消耗更多内存。

3、可能还用到MyISAM引擎，并且 key_buffer_size 设置过大。

不过现在MyISAM引擎大家一般用得也比较少了。

4、程序内存泄漏风险。

可以用valgrind工具检验是否存在这个问题，如果确定的话，可以考虑升级MySQL版本，或者定期在维护时间重启mysqld实例，或者通过高可用切换方式将有风险的实例重启。

5、glibc的内存管理器自身缺陷导致。

简言之，就是调用glibc申请的内存使用完毕后，归还给OS时没有被正常回收，而变成了碎片，随着碎片的不断增长，就能看到mysqld进程占用的内存不断上升。这时候，我们可以调用函数主动回收释放这些碎片。

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
45305 mysql     20   0   28.4g    25g   8400 S  48.5 81.4  64:46.82 mysqld

[root@mysql#] gdb --batch --pid `pidof mysqld` --ex 'call malloc_trim(0)'

  PID USER      PR  NI    VIRT    RES    SHR  S  %CPU %MEM     TIME+ COMMAND
45305 mysql     20   0   28.4g    5.2g   8288 S  2.7  17.0  64:56.82 mysqld

这就像是在InnoDB表中产生太多碎片后，我们主动执行 OPTIMIZE TABLE 重建表的做法。

Enjoy MySQL :)

这就像是在InnoDB表中产生太多碎片后，我们主动执行 OPTIMIZE TABLE
重建表的做法。

----文章结束。

上个月，也写了一篇关于，服务器内存占用问题，当时只是对MySQL本身做了一些操作先释放内存，然后，减少参数配置来减少对内存的使用。

现在结合这篇文件，从操作系统层面回收内存，感觉可以两者结合，效果可能会更好一些。

这里总结一下：

1.调低session级buffer参数值，以及*table_size相关的参数值

2.调整合适的并发连接数和table_open_cache数

3.MySQL数据库服务器还是建议禁用swap

4.做好监控系统基本层面和数据库层面，尤其是MySQL lock相关。

5.系统版本和数据库版本不易过低，尽量能升级就升级到高版本，降低系统本身的缺陷和MySQL程序等的风险。