当时sysbench 来对MYSQL 8.011 版本的数据库进行压测,并发到达100,MYSQL就报OOM , 服务器的配置 4C 16G
基本上在配置上是没有太多的问题和可以被改正的点....问题解决了,但我们的说说怎么产生了这个问题,并且为什么更改了overcommit 问题就解决了....那么到底程序是怎么申请内存的,以MYSQL为例 正在运行的MYSQL 在申请内存时通过malloc()函数,来动态的分配内存,他找到与申请内存大小相同的未使用的连续的块,并且返回给MYSQL 相关的内存空间的指针...当发现这个问题就会根据系统的配置,以及底线,开始使用OOM Killer 来让一些他选择的应用程序终止工作.在LINUX 核心通过一个oom_badness() 的功能来进行工作....实际上这个问题分析是可以写一篇的,这里限于时间和版面的问题,一句话表名就是MYSQL 如果是这个系统的内存大户,那他必然被KILL.