共计 6120 个字符，预计需要花费 16 分钟才能阅读完成。
作者：刘开洋
爱可生交付服务部团队北京 DBA，次要负责解决 MySQL 的 troubleshooting 和我司自研数据库自动化治理平台 DMP 的日常运维问题，对数据库及周边技术有浓重的学习趣味，喜爱看书，谋求技术。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
问题
前几天遇到一个奇怪的问题，服务器内存明明够用，后果在对 MySQL 进行测压的时候却呈现了 OOM，是 Linux 内核出错了吗？
具体景象如下：应用 sysbench 对 mysql 进行压测，并发 50、80 均失常输入，当并发达到 100 时开始报 OOM。
[root@yang-01 ~]# sysbench /usr/share/sysbench/oltp_read_write.lua --mysql-host=yang-02 --mysql-port=3306 --mysql-user=root --mysql-password=*** --mysql-db=test --table-size=100000 --tables=5 --threads=100 --db-ps-mode=disable --auto_inc=off --report-interval=3 --max-requests=0 --time=360 --percentile=95 --skip_trx=off --mysql-ignore-errors=6002,6004,4012,2013,4016,1062 --create_secondary=off run
sysbench 1.0.17 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 100
Report intermediate results every 3 second(s)
Initializing random number generator from current time
Initializing worker threads...
FATAL: mysql_store_result() returned error 5(Out of memory (Needed 48944 bytes))
FATAL: 'thread_run' function failed: /usr/share/sysbench/oltp_common.lua:432: SQL error，errno = 5, state = 'HY000': Out of memory (Needed 48944 bytes)
FATAL: mysql_store_result() returned error 5(Out of memory (Needed 48944 bytes))
FATAL: 'thread_run' function failed: /usr/share/sysbench/oltp_common.lua:432: SQL error，errno = 5, state = 'HY000': Out of memory (Needed 48944 bytes)MySQL 中 error log 的报错为：
······
2021-03-16T09:13:00.692622+08:00 343 [ERROR] [MY-010934] [Server] Out of memory (Needed 708628 bytes)
2021-03-16T09:13:00.692702+08:00 343 [ERROR] [MY-010934] [Server] Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space
2021-03-16T09:13:59.832037+08:00 374 [ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: ut0ut.cc:678:!m_fatal
InnoDB: thread 140375101384448
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
01:13:59 UTC - mysqld got signal 6 ;剖析
对 MySQL OOM 咱们一步步进行剖析，首先应该查看 ulimit 限度，
[root@yang-02 ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 23045
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 23045
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited零碎并没有对 ulimit 进行限度，100 个并发量连贯在咱们的配置之内，那就不是 ulimit 配置的问题，接下来剖析下内存的应用状况，
在复现 MySQL OOM 的过程中，查看对应内存应用，通过 top 和 free 命令进行监控，失去以下信息，
[root@yang-02 ~]# free -m
total used free shared buff/cache available
Mem: 16047 1958 8956 8 5132 13920
Swap: 5119 0 5119
[root@yang-02 ~]# top
top - 17:21:30 up 32 min, 4 users, load average: 0.00, 0.04, 0.11
Tasks: 226 total, 2 running, 224 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.2 us, 0.6 sy, 0.0 ni, 97.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 16432236 total, 9164596 free, 2012156 used, 5255484 buff/cache
KiB Swap: 5242876 total, 5242876 free, 0 used. 14247508 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7654 root 20 0 13.7g 1.7g 14312 S 1.3 10.3 0:00.27 mysqld这里看咱们的内存应用很失常，free 和 available 都很多，swap 都没有应用，惟一存在异样的是虚拟内存有点高，咱们接着剖析：
进一步查看一下 /proc/meminfo，具体分析一下内存的应用状况，其中以下两个参数引起了留神：
[root@yang-02 ~]# cat /proc/meminfo | grep Commit
CommitLimit: 13458992 kB
Committed_AS: 13244484 kB一般来说 CommitLimit 的值是要比 Committed_AS 的值要小的，联合当初内存的应用，咱们应该留神到一个 OS kernel 参数
[root@yang-02 ~]# cat /etc/sysctl.conf |grep vm.overcommit_memory
vm.overcommit_memory=2将 vm.overcommit_memory 调整为 0，压测时 MySQL OOM 隐没了。
这三个参数值是什么意思呢？它和我的内存应用的关系是什么？内存真的够用吗？通过翻看 Linux 的内核文档咱们来进行具体阐明。
剖析 vm.overcommit_memory 的应用
首先解释下什么叫 overcommit，overcommit 的意思是指操作系统承诺给过程的内存大小超过了理论可用的内存。
从内核版本 2.5.30 开始，这个参数的三种取值别离为：
overcommit_memory：This value contains a flag that enables memory overcommitment.
- When this flag is 0, Heuristic overcommit handling, the kernel attempts to estimate the amount of free memory left when userspace requests more memory. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slightly more memory in this mode. This is the default.
- When this flag is 1, Always overcommit, the kernel pretends there is always enough memory until it actually runs out. Appropriate for some scientific applications. Classic example is code using sparse arrays and just relying on the virtual memory consisting almost entirely of zero pages.
- When this flag is 2, Don’t overcommit, the kernel uses a “never overcommit” policy that attempts to prevent any overcommit of memory. The total address space commit for the system is not permitted to exceed swap + a configurable amount (default is 50%) of physical RAM. Depending on the amount you use, in most situations this means a process will not be killed while accessing pages but will receive errors on memory allocation as appropriate.
中文释义：
- 当这个标记为 0 时，示意试探性的 overcommit，当用户空间申请更多内存时，OS kernel 会预估残余的闲暇内存量，如果内存申请特地大就会被回绝。例如 malloc() 一次性申请的内存大小就超过了 swap 和 physical RAM 的和，就会受到 kernel 回绝 overcommit。
- 当这个标记为 1 时，kernel 会伪装始终有足够的内存，直到理论用完为止。
- 当这个标记为 2 时，kernel 应用“永不适度提交”的策略，试图阻止任何内存的适度提交。
从含意中剖析，如果咱们将 vm.overcommit_memory 的值设为 2，就很有可能呈现内存申请的值超过咱们的阈值，就会受到禁止。
该阈值是通过内核参数 vm.overcommit_ratio 或 vm.overcommit_kbytes 间接设置的，从对应参数解释中失去公式如下：
CommitLimit = Physical RAM * vm.overcommit_ratio + Swap // vm.overcommit_ratio 是内核参数，默认值是 50，示意物理内存的 50%。测试环境中 Physical RAM 的值约为 16G，Swap 的值约为 5G，计算下来可正对应 CommitLimit 的值 13 个 G。
/proc/meminfo 中的 Committed_AS 示意所有过程曾经申请的内存总大小，而咱们查问的 free 和 top 下的内存则是过程曾经调配的内存。
Committed_AS 是 OS kernel 对所有过程在最坏状况下须要多少 RAM/swap 的预估，能力保障工作负载不会呈现 OOM(内存不足)，因而会存在适度申请提交内存的景象。
这个值是零碎所有运行的程序所申请的内存大小，并不代表着调配应用的大小，而且各个程序申请的内存是可共享的。
尽管 Committed_AS 的数值与虚拟内存 VIRT 的大小很类似，目前没有找到官网阐明他们之间的分割，但通过屡次测试，它的大小和虚拟内存并没有关系。
后果
如果 Committed_AS 超过 CommitLimit 就示意产生了 overcommit，超出越多示意 overcommit 越重大，kernel 的 killer 会挑一部分过程干掉，如果内存不够还会持续被 killer 干掉，MySQL 在内存占用中属于大头，首当其冲。
测试环境查看 Committed_AS 和 CommitLimit 的参数值为：
[root@yang-02 ~]# cat /proc/meminfo | grep Commit
CommitLimit: 13458992 kB
Committed_AS: 13244484 kB两者曾经非常靠近，非常容易产生 MySQL 的 OOM，因而须要调整的是减少内存或者将 vm.overcommit_memory 的值设为 0/1，具体须要依据环境变更。
附：还有两个参数与咱们这次的内存调配有关系，不过影响不大，有趣味的同学能够自行谷歌：admin_reserve_kbytes 和 user_reserve_kbytes。
参考：
https://www.kernel.org/doc/Do…
https://www.kernel.org/doc/Do…
http://lwn.net/Articles/28345/
https://www.win.tue.nl/~aeb/l…
