背景
最近发现在压力测试MySQL时候有重启情况，查看日志，也只是一大堆回滚日志啥的
InnoDB: Progress in percents: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 1002018-06-04 20:59:05 20990 [Note] InnoDB: Rollback of trx with id 19528681 completed
于是乎果断查看/var/log/messages日志，从日志中找到了有用的信息
Jun 4 05:49:26 localhost kernel: Out of memory: Kill process 12600 (mysqld) score 458 or sacrif
ice child
Jun 4 05:49:26 localhost kernel: Killed process 12600 (mysqld) total-vm:59075508kB, anon-rss:54
677236kB, file-rss:0kB
内存溢出Linux为了保护系统不崩溃，将按照它的机制将“内存大户”mysql给干掉了，呜呜呜。。。
看来有必要仔细了解下Linux的OOM Killer机制了。
OOM
linux系统为了避免在内存不足的时候出现严重问题，在出现内存不足时候使用OOM killer机制将一些其他的进程杀掉来释放一些内存。
以下是关于它的英文翻译：
默认情况下，Linux遵循乐观的内存分配策略。这意味着当 malloc()返回非空时不能保证内存真的可用。这是一个非常糟糕的错误。如果事实证明系统内存不足，一个或多个进程将被臭名昭著的OOM Killer杀死。如果使用Linux在不希望突然失去一些随机挑选的过程的情况下，而且内核版本是最新的，可以使用这样的命令关闭这种过度提交行为：
echo 2 > /proc/sys/vm/overcommit_memory
overcommit_memory的值：
0：启发式策略，可以允许轻微的overcommit。
1：永远允许overcommit。
2：永远禁止overcommit，系统分配的内存不会超过swap+ram*overcommit_ratio系数默认50%
[root@localhost ~]# cat /proc/sys/vm/overcommit_ratio
50
内存使用完毕后，在此申请内存会报错，表示再也不可能运行新程序。
挑选杀掉的进程是按照：内存消耗量、CPU时间（utime+stime）、存活时t间（utime-stat time）和oom_adj计算出来的。oom_adj是OOM权重，在/proc/<pid>/oom_adj里面，取值是-17到+15，取值越高，越容易被干掉。
若是想避免哪个程序被干掉，可以修改oom_adj为-17
总的来说就是那个程序运行时间越长，占用内存越大它的打分就会越高，就越容易被挑出来干掉。
知道了程序意外重启的原因，下面就是他的解决办法
1，检查程序的配置是否合理，运行时候是否负载过大，倘若程序确实需要消耗大量的内存无法避免，那就提高硬件配置，或者考虑横向扩展等等。
2， 将/proc/sys/vm/overcommit_memory设置为2，但是在要是新的程序连接过来就会直接drop掉无法运行，并不推荐。
