关于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了
Leave a reply