MySQL 5.7 OOM问题诊断——就是这么简单

转载自：http://www.sohu.com/a/114903225_487483

Inside君最近把金庸先生的笑傲江湖重看了三遍，感慨良多。很多工作、管理、生活、学习上的问题都能在其中一窥究竟，而那是年轻时所不能体会的一种感悟。比如下面的这段话：

风清扬又道：“单以武学而论，这些魔教长老们也不能说真正已窥上乘武学之门。他们不懂得，招数是死的，发招之人却是活的。死招数破得再妙，遇上了活招数，免不了缚手缚脚，只有任人屠戮。这个‘活’字，你要牢牢记住了。学招时要活学，使招时要活使。倘若拘泥不化，便练熟了几千万手绝招，遇上了真正高手，终究还是给人家破得干干净净。”

今天，来谈谈MySQL的OOM（out of memory）问题诊断。之前，这类问题的定位对于普通用户来说并不怎么简单。但是在MySQL 5.7中，OOM问题的定位变得极其容易。还没掌握的小伙伴赶快来看下吧。通常来说，发生OOM时可在系统日志找到类似的日志提示：

[3207032.031552] bash invoked oom-killer: gfp_mask=0x280da,order=0, oom_score_adj=0

[3207032.031561] bash cpuset=/ mems_allowed=0-1

[3207032.031566] CPU: 1 PID: 5019 Comm: bash Not tainted3.10.0-327.22.2.el7.x86_64 #1

[3207032.031568] Hardware name: Huawei Technologies Co.,

[3207032.031570] ffff8802322b7300 00000000922e27ce ffff8803f0c9baf8 ffffffff816360fc

[3207032.031576] ffff8803f0c9bb88 ffffffff8163109c ffff88003547bde0 ffff88003547bdf8

[3207032.031579] 0000000000000206 ffff8802322b7300 ffff8803f0c9bb70 ffffffff81128c7f

[3207032.031583] Call Trace:

[3207032.031596] [<ffffffff816360fc>] dump_stack+0x19/0x1b

[3207032.031600] [<ffffffff8163109c>] dump_header+0x8e/0x214

[3207032.031614] [<ffffffff81128c7f>] ? delayacct_end+0x8f/0xb0

[3207032.031620] [<ffffffff8116d20e>] oom_kill_process+0x24e/0x3b0

[3207032.031623] [<ffffffff8116cd76>] ? find_lock_task_mm+0x56/0xc0

[3207032.031626] [<ffffffff8116da36>] out_of_memory+0x4b6/0x4f0

[3207032.031630] [<ffffffff81173c26>] __alloc_pages_nodemask+0xaa6/0xba0

[3207032.031637] [<ffffffff811b7eba>] alloc_pages_vma+0x9a/0x150

[3207032.031643] [<ffffffff81197a85>] handle_mm_fault+0xb85/0xf50

[3207032.031648] [<ffffffff81641d80>] __do_page_fault+0x150/0x450

[3207032.031651] [<ffffffff816420a3>] do_page_fault+0x23/0x80

[3207032.031656] [<ffffffff8163e308>] page_fault+0x28/0x30

MySQL 5.7的库performance_schema新增了以下这几张表，用于从各维度查看内存的消耗：

• 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

简单来说，就是可以根据用户、主机、线程、账号、全局的维度对内存进行监控。同时库sys也就这些表做了进一步的格式化，可以使得用户非常容易的观察到每个对象的内存开销：

细心的同学可能会发现，默认情况下performance_schema只对performance_schema进行了内存开销的统计。但是在对OOM进行诊断时，需要对所有可能的对象进行内存监控。因此，还需要做下面的设置：

mysql> update performance_schema.setup_instruments set

enabled = 'yes' where name like 'memory%';

Query OK, 310 rows affected (0.00 sec) Rows matched: 380 Changed: 310 Warnings: 0

但是这种在线打开内存统计的方法仅对之后新增的内存对象有效：

如想要对全局生命周期中的对象进行内存统计，必须在配置文件中进行设置，然后重启：

通过上面的结果，有小伙伴是不是已经发现可疑的内存使用了呢？memory/innodb/os0file这个对象使用了1.42G内存，而整个数据库实例的Buffer

Pool只有1.05G。那么这时就可以去bugs.mysql.com上去搜索下。果不其然，是一官方已知问题，并已在5.7.14中修复。

通过类似方法Inside君已经定位了5起OOM问题。当然，这里Inside君只是给了一个思路，活学活用，才能达到无招胜有招的至臻境界。