linux中有一个overcomit的配置，这个配置关系到进程在过多申请memory资源的时候，系统的表现（启发式允许，不检查，or 阻止）
/proc/sys/vm/overcommit_memory This file contains the kernel virtual memory accounting mode. Values are: 0: heuristic overcommit (this is the default) 1: always overcommit, never check 2: always check, never overcommit In mode 0, calls of mmap(2) with MAP_NORESERVE are not checked, and the default check is very weak, leading to the risk of getting a process "OOM-killed". In mode 2 (available since Linux 2.6), the total virtual address space that can be allocated (CommitLimit in /proc/mem‐ info) is calculated as CommitLimit = (total_RAM - total_huge_TLB) * overcommit_ratio / 100 + total_swap
详细的理解可以参见这个博客： http://linuxperf.com/?p=102
在实际项目中，如果机器是跑redis的一般都会把overcomit开成1 （https://redis.io/topics/faq#background-saving-fails-with-a-fork-error-under-linux-even-if-i-have-a-lot-of-free-ram）
Short answer: echo 1 > /proc/sys/vm/overcommit_memory :)
跑ffmepg的时候，也会设置成1。避免ffmepg一些进程在申请内存的时候发生内部错误。
根本原因是进程申请了这么多memory，实际不一定占用这么多memory，而且物理内存页的分配发生在使用的瞬间，而不是在申请的瞬间。所以我们可以允许系统overcommit，满足进程申请，可以通过cgroup memory来限制用户使用内存的上限。
原文：https://www.cnblogs.com/yanghuahui/p/9473609.html