panic_on_oom(/proc/sys/vm/panic_on_oom)判断系统出现oom时要做的操作。接受的三个值如下：0-默认值，发生oom时触发oomkiller1-程序在cpuset、memorypolicy、memcg的约束下发生OOM，可以考虑启动OOMkiller而不是panic。其他情况触发kernelpanic，即系统直接重启2-当oom发生时，直接触发kernelpanic，即系统直接重启。linux用户内存是在读写时分配的，所以系统发现需要的内存基本都发生在handle_mm_fault()有时（其他特殊进程类似，此处忽略），handle_mm_fault()需要为缺失的页分配内存，它会调用alloc_pages()系列函数，从而调用prepare_alloc_pages()，然后进入__alloc_pages_direct_reclaim()，这里可以清除磁盘上的缓冲区一次。在此之后，内存仍然没有分配，所以我们必须进入OMMKiller（pagefault_out_of_memory()）。在这种状态下，系统中的内存可能只被正在运行的进程和内核占用。如果大家都不让，系统就只有死路一条。为了防止系统物理内存不够时系统崩溃，选择一个内存占用最高的程序，杀掉它！Swap：在Linux中，当物理内存不够用，有新程序申请内存分配时，Linux会选择将其他程序暂时不用的数据交换到物理磁盘（swapout），等待程序使用是时候读入（换入）了。这样做的缺点是显而易见的。换入/换出的成本相对较高。与将数据保存在内存中相比，读取磁盘的操作要多一些。OOM：outofmemory是指在Linux中，系统会选择保护一些系统进程，同时杀掉一些其他进程来释放内存。如何防止进程因为OOM机制被杀死？OOM相关的几个文件是/proc//oom_adj、/proc//oom_score。前者是一个从-16到15的权重，默认为0，设置为-17表示永不被杀死，其他情况下，该值越大越容易被杀死。后者是它计算出来的一个值，根据这个值选择杀死哪些进程。swap中第三个方法的overcommit参数放在上面，因为分配不到内存就会返回错误，所以内存永远不会用完。OOM不会受到影响。参考文档：https://blog.csdn.net/hu_jing...`
