【20180611】MySQL OOM

关于MySQL OOM的排查思路

服务器发生内存泄露

1. 如何确认服务器发生内存泄漏:
   • 通常执行free -m就查看内存的使用状况就能够了。假如cached和used的值相差特别大的话，安么这个时候咱们能够认为发生了内存泄漏。（通常在CentOS6的版本上面能够这么认为,可是这个说法暂时尚未一个比较可信的依据）
   • buffer和cache的区别:
     • buffer: 缓冲，为了提升内存和硬盘之间的数据交换的速度而设计的，是即将要写入磁盘的。
     • cache: 缓存，是为了提升CPU和内存之间的数据交换速度而设计的，也就是日常见到的一级缓存，二级缓存，三级缓存,cache是从被磁盘中读出来的。
   • 内存使用状况的计算方式()
     • total = used+free
     • buffer和cache是包含在used内的
     • buffer和cache多是被分配出去，可是实际可能有部分cache或者buffer没有被使用
     • -/+ buffer/cache 这行中used是实际使用的内存，free是实际可以使用的空闲内存

[root@t-filter1 liuhuang]# free -m
             total       used       free     shared    buffers     cached
Mem:          7870       2567       5302          0        584       1083
-/+ buffers/cache:        898       6971
Swap:         2047       1262        785
[root@t-filter1 liuhuang]#

2. 内存泄漏一些应急处理状况(特指MySQL)
   • 选择重启进程，完全释放内存归还给OS
   • 找到代码中致使泄漏的代码，并加以修复
   • 升级程序版本，一般新版本会解决旧版本的问题

MySQL查看内存泄露

MySQL5.7的库performance_schema新增了几张视图，能够用于各个维度查看内存的使用状况,还有就是这个几个视图的信息还能够在sys这个库中查看:

root@mysqldb 11:18:  [performance_schema]> show tables like 'memory%';
+-----------------------------------------+
| Tables_in_performance_schema (memory%)  |
+-----------------------------------------+
| memory_summary_by_account_by_event_name |
| memory_summary_by_host_by_event_name    |
| memory_summary_by_thread_by_event_name  |
| memory_summary_by_user_by_event_name    |
| memory_summary_global_by_event_name     |
+-----------------------------------------+
5 rows in set (0.00 sec)

root@mysqldb 14:45:  [performance_schema]>

从表的名字大体就能够看出，就是根据主机，进程，用户，全局等维度对内存进行监控。同时sys也针对这些表的格式作了进一步的优化，使得咱们能够很方便的查看。

须要注意的一点就是部份内存维度的监控默认是关闭的，并非全部的内存监控维度是开启的，还须要本身手动开启这些监控信息:

root@mysqldb 14:51:  [performance_schema]> update setup_instruments set enabled='yes' where name like 'memory%';

还有就是这些监控的信息只是会从当前使用的状况开始进行监控的，以前的内存使用状况是没法获取获得的。

1. 查看全局内存使用状况:

root@mysqldb 14:57:  [performance_schema]> select event_name,SUM_NUMBER_OF_BYTES_ALLOC  from     memory_summary_global_by_event_name       order by SUM_NUMBER_OF_BYTES_ALLOC desc LIMIT 10;
+------------------------------------------------------------------------------+---------------------------+
| event_name                                                                   | SUM_NUMBER_OF_BYTES_ALLOC |
+------------------------------------------------------------------------------+---------------------------+
| memory/performance_schema/events_statements_history_long                     |                  14320000 |
| memory/performance_schema/events_statements_summary_by_digest.tokens         |                  10240000 |
| memory/performance_schema/events_statements_history_long.tokens              |                  10240000 |
| memory/performance_schema/events_statements_history_long.sqltext             |                  10240000 |
| memory/performance_schema/table_handles                                      |                   9502720 |
| memory/performance_schema/events_statements_summary_by_thread_by_event_name  |                   9091072 |
| memory/performance_schema/memory_summary_by_thread_by_event_name             |                   5898240 |
| memory/performance_schema/events_statements_summary_by_digest                |                   5120000 |
| memory/performance_schema/events_statements_summary_by_host_by_event_name    |                   4545536 |
| memory/performance_schema/events_statements_summary_by_account_by_event_name |                   4545536 |
+------------------------------------------------------------------------------+---------------------------+
10 rows in set (0.01 sec)

2. 查看进程内存使用状况:

root@mysqldb 14:58:  [performance_schema]> select event_name, SUM_NUMBER_OF_BYTES_ALLOC from     memory_summary_by_thread_by_event_name       order by SUM_NUMBER_OF_BYTES_ALLOC desc limit 20;
+----------------------------------------------+---------------------------+
| event_name                                   | SUM_NUMBER_OF_BYTES_ALLOC |
+----------------------------------------------+---------------------------+
| memory/sql/Relay_log_info::mts_coor          |                         0 |
| memory/sql/QUICK_RANGE_SELECT::alloc         |                         0 |
| memory/sql/table_mapping::m_mem_root         |                         0 |
| memory/sql/sp_head::call_mem_root            |                         0 |
| memory/sql/sp_head::execute_mem_root         |                         0 |
| memory/sql/sp_head::main_mem_root            |                         0 |
| memory/sql/THD::sp_cache                     |                         0 |
| memory/sql/Warning_info::m_warn_root         |                         0 |
| memory/sql/Protocol_local::m_rset_root       |                         0 |
| memory/sql/Prepared_statement::main_mem_root |                         0 |
| memory/sql/Prepared_statement_map            |                         0 |
| memory/sql/servers                           |                         0 |
| memory/sql/Table_triggers_list               |                         0 |
| memory/sql/gdl                               |                         0 |
| memory/sql/new_frm_mem                       |                         0 |
| memory/sql/help                              |                         0 |
| memory/sql/thd::main_mem_root                |                         0 |
| memory/sql/Delegate::memroot                 |                         0 |
| memory/sql/THD::transactions::mem_root       |                         0 |
| memory/sql/display_table_locks               |                         0 |
+----------------------------------------------+---------------------------+
20 rows in set (0.01 sec)

这个时候咱们能够根据这些进程名去google或者其余的搜索引擎去获取获得这些相关的信息，这个时候就能够比较很明确的根据具体的状况在进行优化和调整。

NUMA也有可能致使内存泄露

1. 什么是NUMA
   • 能够移步到：http://cenalulu.github.io/linux/numa/
   • NUMA是为了解决SMP系统进程增加致使进程竞用和横向扩展槽糕的问题，它会将CPU平均划分红若干个Chip(最多不超过4个)，每一个Chip都有本身的内存控制器和内存插槽，可是须要注意的是每一个Chip的内存分配并非均衡的，而且进程在本地的Chip访问本地内存的速度是正常的速度，可是当当前的Chip的内存不足，须要访问远程内存(非本地的Chip)会比本来的慢。
2. 查看NUMA的开启状况和内存分配状况
   • 我本地的测试是只分配了一个node的。

[root@TiDB-node2 ~]# numactl --show
policy: default
preferred node: current
physcpubind: 0 1 2 3 4 5 6 7
cpubind: 0
nodebind: 0
membind: 0
[root@TiDB-node2 ~]#

[root@TiDB-node2 ~]# numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 8191 MB
node 0 free: 4093 MB
node distances:
node   0
  0:  10
[root@TiDB-node2 ~]#

3. 关闭NUMA
   • 在BIOS设置层面关闭NUMA，缺点是须要重启OS。
   • 或修改GRUB配置文件，缺点也是须要重启OS。
   • 升级MySQL版本到5.6.27及之后，新增了一个选项innodb_numa_interleava,只须要重启MySQL实例，无需重启OS。
     • MySQL 5.6.27/5.7.9开始引用innodb_numa_interleave选项，可是在5.7.11的Release Notes里提到numa对于online resize buffer pool支持很差，估计是这个缘由致使在这以后又临时禁用了，但官方文档里面没有写清楚。不过percona里面一值有这个选项，能够放心使用。

关于MySQL内存泄露的一些BUG

1. 同时开启P_S和thread pool会致使内存泄露(percona 5.7.17版本)

   • 更早以前官方的5.7.13版本也有发生过这个状况
2. 表mysql.gtid_executed的压缩失败致使记录不断的增加，内存不断的增长致使OOM
   • MySQL 5.7.17以及以前的版本，当从库设置super_read_only=1的时候，MySQL会认为当前是可读的，应该阻止全部的DML操做，所以GTID合并线程也会失败。
   • MySQL 5.8虽然已经修复了这个问题,可是所以导入了新的bug:

The MySQL server is running with the --super-read-only option so it cannot execute this statement

要完全解决这个问题，务必须要升级到MySQL5.7.19版本。