MySQL OOM（内存溢出）的解决思路

MySQL OOM（内存溢出）的解决思路（内存溢出）的解决思路

主要介绍了MySQL OOM（内存溢出）的解决思路，文中讲解非常细致，帮助大家在学习工作中解决内存溢出的问题，感兴趣的朋友可以了解下

OOM全称"Out Of Memory"，即内存溢出。

内存溢出已经是软件开发历史上存在了近40年的“老大难”问题。在操作系统上运行各种软件时，软件所需申请的内存远远超出了物理内存所承受的大小，就叫内存溢出。

内存溢出产生原因多种多样，当内存严重不足时，内核有两种选择：

1. 直接panic

2. 杀掉部分进程，释放一些内核。

大部分情况下，会杀掉导致OOM的进程，然后系统恢复。通常我们会添加对内存的监控报警，例如：当memory或swap使用超过90%时，触发报警通知，需要及时介入排查。

能为下面情况：

[root@localhost ~]# free -m total used free shared buffers cachedMem: 128937 128527 409 1 166 1279-/+ buffers/cache: 127081 1855Swap: 16383 16252 131

可以看出此时的内存使用已经很高了，物理内存和swap虚拟内存几乎都被用完，buffers和cached也不多，随时可能出现OOM的情况。

首先，通过top命名查看占用内存最大的进程：

shift+o可以选择排序方式，n代表%MEM。

[root@localhost ~]# topMem: 132031556k total, 131418864k used, 612692k free, 212104k buffersSwap: 16777212k total, 0k used, 16777212k free, 14648144k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND14920 mysql 20 0 125g 109g 6164 S 6.6 87.0 27357:08 mysqld

可以看出mysqld进程占用内存最大，也可以这样查：

[root@localhost ~]# ps -e -o 'pid,comm,args,pcpu,rsz,vsz,stime,user,uid' | grep -E 'PID|mysql' |grep -v grep PID COMMAND COMMAND %CPU RSZ VSZ STIME USER UID25339 mysqld /export/servers/mysql/bin/m 9.4 115001324 130738976 2017 mysql 50032070 mysqld_safe /bin/sh /export/servers/mys 0.0 296 106308 2017 root 0

RSZ为进程占用私有内存大小，单位Kb。

*************************** 1. row *************************** @@key_buffer_size: 67108864 @@query_cache_size: 0 @@tmp_table_size: 268435456 @@innodb_buffer_pool_size: 38654705664@@innodb_additional_mem_pool_size: 134217728 @@innodb_log_buffer_size: 8388608 @@max_connections: 3000 @@read_buffer_size: 4194304 @@read_rnd_buffer_size: 4194304 @@sort_buffer_size: 2097152 @@join_buffer_size: 2097152 @@binlog_cache_size: 32768 @@thread_stack: 262144

每个参数配置说明：

innodb_buffer_pool_size 占用内存最大的参数

innodb_additional_mem_pool_size 额外内存，mysql5.7以后移除

innodb_log_buffer_size 重做日志缓存大小

key_buffer_size 只用于MyISAM引擎，不需要太大

tmp_table_size 临时表缓存大小

query_cache_size 查询缓存，建议关闭

max_connections 最大连接数

read_buffer_size read_rnd_buffer_size sort_buffer_size join_buffer_size

这些参数都跟线程有关，所占内存为这些参数的和*最大连接数。连接数越多占用内存也就越多，建议不超过

innodb_buffer_pool在mysql中占有最大内存，将innodb_buffer_pool_size调小可以有效降低OOM问题。但如果设置太小会导致内存刷脏页频率增加，IO增多，从而降低性能。通常我们认为

innodb_buffer_pool_size为系统内存的60%~75%最优。

查看buffer_pool的使用情况：

MYSQL >select POOL_ID,POOL_SIZE,FREE_BUFFERS,DATABASE_PAGES,OLD_DATABASE_PAGES,MODIFIED_DATABASE_PAGES,PAGES_MADE_YOUNG,PAGES_NOT_MADE_YOUNG from information_schema.INNODB_BUFFER_POOL_STATS;+---------+-----------+--------------+----------------+--------------------+-------------------------+------------------+----------------------+| POOL_ID | POOL_SIZE | FREE_BUFFERS | DATABASE_PAGES | OLD_DATABASE_PAGES | MODIFIED_DATABASE_PAGES | PAGES_MADE_YOUNG | PAGES_NOT_MADE_YOUNG |+---------+-----------+--------------+----------------+--------------------+-------------------------+------------------+----------------------+| 0 | 611669 | 1024 | 610644 | 225393 | 0 | 309881 | 0 || 1 | 611669 | 1024 | 610645 | 225393 | 0 | 309816 | 0 || 2 | 611669 | 1024 | 610645 | 225393 | 0 | 309756 | 0 |+---------+-----------+--------------+----------------+--------------------+-------------------------+------------------+----------------------+

可以看出buffer_pool分了3个实例，POOL_SIZE为每个实例大小，这里为页个数，我们知道mysql页的默认大小为16K，所以单个实例的真正大小为611669*16K，5.6以后要求FREE_BUFFERS至少保留

1024个页，少于1024个页时会强制刷脏数据，后面的值可以看出脏页情况。另外如果PAGES_MADE_YOUNG远大于PAGES_NOT_MADE_YOUNG页数，那么此时内存使用就可能比较大，可以适当降

低innodb_buffer_pool_size大小。

另一篇文章也有对buffer_pool的介绍：一条命令解读InnoDB存储引擎—show engine innodb status

如果innodb_buffer_pool_size不是很大，但内存还是很高，也可能是由于并发线程太多导致，需要确认是不是应用异常，还是需要调整max_connections最大连接。如果连接太多，每个连接也会占用独立

的内存，read、sort、join缓存都是session级别，连接越多需要内存就越多，所以这些参数也不能设置太大。

查看mysql服务打开文件数限制：

MySQL >show global variables like 'open_files_limit';+------------------+-------+| Variable_name | Value |+------------------+-------+| open_files_limit | 65535 |+------------------+-------+

查看操作系统打开文件数限制：

[root@localhost ~]# ulimit -amax memory size (kbytes, -m) unlimitedopen files (-n) 65535

如果此时打开的文件很多，内存也会占用很多。

其次，还需看一下table_open_cache，当打开一个表后会把这个表的文件描述符缓存下来。