关于linux内存管理的两个概念

swap:在linux里面,当物理内存不够用了,而又有新的程序请求分配内存,那么linux就会选择将其他程序暂时不用的数据交换到物理磁盘上(swap out),等程序要用的时候再读进来(swap in)。这样做的坏处显而易见,swap in/swap out这里的代价比较大,相比数据一直放在内存里面,多了读磁盘的操作,而磁盘IO代价。。大家都懂的。
OOM:out of memory,指在linux里面,由于系统内存压力,系统会选择保护一些系统进程,而将一些其他的进程kill掉,释放内存。

禁止swap

可以设置/proc/sys/vm/swappiness=0,不过这就禁用了所有进程使用swap
给进程分配内存的时候,让它使用hugepage内存。设置方法:
1>vi /etc/sysctl.conf ; 添加 vm.nr_hugepages=hugepage_num(多少页大页内存,这个必须大于进程需要的最大内存,比如mysqld buffer pool=5G,那么hugepage_num*page_size>5G) ; sysctl -p 生效。
2>这样可以防止进程使用hugepage的原因:在进程使用hugepage分配内存时,是一次性分配、且独占的,既然一次性已经分配满了那也不存在使用swap的理由,你可以通过top命令看到进程一开始就占用了你所为它设定大小的内存。
可以设置/proc/sys/vm/overcommit_memory=2(其他值代表什么含义,可以自己www.linuxidc.com,另外自己测试中发现这个值如果大于2,那么效果和2一样) 在值为2的情况下,可以分配的内存最大大小在swap size + RAM*((/proc/sys/vm/overcommit_ratio) / 100)),如果大于这个直接返回错误,这个也是类似hugepage分配内存,也是一次性,独占(不能100%肯定),但是利用top命令查看,它显示当前已占用的内存大小不是我们为他设定的那个值。那为什么我认为它也是独占、且一次性分配呢?因为启动其他进程的时候,直接报错:
Error occurred during initialization of VM
Could not reserve enough space for object heap
使用mysql自带的参数–memlock 它将内存锁定,原理同hugepage一样,不过缺陷是必须由root运行mysqld
避免进程因为OOM机制被kill掉

与OOM相关的几个文件是 /proc//oom_adj 、 /proc//oom_score。前者是一个权值-17至15。设置为0表示永远不被kill,其余情况值越大越容易被kill。后者就是它计算出来的一个值,就是根据这个值来选择哪些进程被kill掉的。
上面放置使用swap中的第三个方法 overcommit参数,因为它分配不出内存就会返回错误,所以永远也不能达到内存被耗尽。OOM也就不会有影响了。
echo -17 > /proc/<pid>/oom_adj
1
关于OOM

OOM_killer是Linux自我保护的方式,当内存不足时不至于出现太严重问题,有点壮士断腕的意味
在kernel 2.6,内存不足将唤醒oom_killer,挑出/proc//oom_score最大者并将之kill掉

为了保护重要进程不被oom-killer掉,我们可以:echo -17 > /proc//oom_adj,-17表示禁用OOM
我们也可以对把整个系统的OOM给禁用掉:
sysctl -w vm.panic_on_oom=1 (默认为0,表示开启)
sysctl -p

值得注意的是,有些时候 free -m 时还有剩余内存,但还是会触发OOM-killer,可能是因为进程占用了特殊内存地址

平时我们应该留意下新进来的进程内存使用量,免得系统重要的业务进程被无辜牵连
可用 top M 查看最消耗内存的进程,但也不是进程一超过就会触发oom_killer
参数/proc/sys/vm/overcommit_memory可以控制进程对内存过量使用的应对策略
当overcommit_memory=0 允许进程轻微过量使用内存,但对于大量过载请求则不允许(默认)
当overcommit_memory=1 永远允许进程overcommit
当overcommit_memory=2 永远禁止overcommit

实例

在做大规模图划分时,由于单个进程占用内存很大,易导致进程被系统kill,系统设置启动oom阈值应该是300
当进程被kill之后,使用dmesg命令可以查看系统报错,如下:
第一次:

第二次:

为了实验,只能强制关闭OOM了