作者：吴聪
OOM是Linux中一个比较常见的情况，PostgreSQL数据库触发OOM现象就是数据库进程被KILL了。OOM发生的原因有很多，这里我们从OOM的产生以及如何在PostgreSQL中预防OOM发生来进行研究。
OOM介绍
什么是OOM？
OOM（out-of-memory），顾名思义就是内存溢出了，之所以会出现这种情况和内存分配的overcommit有关。
Linux为了保证在有限的内存中尽可能多的运行更多的进程，在内存分配策略中提出了overcommit的策略，即允许内存溢出。之所以可以这么做是因为我们进程在申请内存时并不会立刻分配内存页，而是到使用时才进行分配。所以Linux才允许进程overcommit，因为即使申请了这么多实际可能也用不到，所以便允许进程申请了。
那么这么做有什么好处呢？对于一些内存敏感的应用来说，随时可能发生新的内存分配，而LINUX中有大量并发的进程，临时使用内存的总量变化很大。很多内存分配需求是临时性的，那么如果不凑巧，有时候要分配内存的时候，物理内存已经分配完了，虽然几毫秒后很可能就有一些内存可以归还，另外还有一些进程分配了内存后没有马上使用，但是如果不能内存超分配，这时候内存分配就会失败。而如果能够支持内存超分配，那么就可以利用这个时间差，有效的解决这个内存短期不足的问题。
但是这么做便会导致内存不足的情况，当出现这种情况时，有两种选择，一种是直接panic系统，然后几秒钟后LINUX自动重启，这个行为可以通过kernel.panic_on_oom参数设置，不过我们一般不采用这种模式。另一种就是我们要说的OOM了，挑出某个进程kill掉来释放内存。
我们可以通过内核参数 vm.overcommit_memory 设置是否使用memory overcommit。
- 0 – Heuristic overcommit handling. 这是缺省值，它允许overcommit，但过于明目张胆的overcommit会被拒绝，比如malloc一次性申请的内存大小就超过了系统总内存。Heuristic的意思是“试探式的”，内核利用某种算法猜测你的内存申请是否合理，它认为不合理就会拒绝overcommit。
- 1 – Always overcommit. 允许overcommit，对内存申请来者不拒。
- 2 – Don’t overcommit. 禁止overcommit。
OOM流程
OOM kill的流程导致如下：
除此之外，为了防止某些情况进程被误kill，将会进行以下检查：
- 是否有足够的交换空间 (nr_swap_pages 0) ？如果是，不进行OOM；
- 自上次失败以来是否已经超过 5 秒？如果是，不进行OOM；
- 是在最后一秒内失败了吗？如果不是，不进行OOM；
- 如果至少在过去 5 秒内没有发生 10 次失败，就不进行 OOM；
- 是否有进程在过去 5 秒内被杀死？如果是，不进行OOM
如何选择进程进行OOM？
函数 select_bad_process() 负责选择要杀死的进程。它通过逐步执行每个正在运行的任务并计算它是否适合使用函数 badness() 进行终止来决定。 Badness 计算如下：
badness_for_task = total_vm_for_task / (sqrt(cpu_time_in_seconds) *
sqrt(sqrt(cpu_time_in_minutes)))
上面这个公式简单来说就是倾向于kill占用内存大执行时间短的进程。
我们可以通过设置进程的oom_score来降低被oom kill的优先级。
oom_score在新版本的Linux内核中计算起来十分简单，就是这个进程占用的（物理内存+SWAP）的总和乘以10，也就是说某个进程的最大oom_score=1000,最小oom_score=0。oom killer总是根据这个值从高到低排序来查找可以杀死的进程，这样确保杀死进程后，可以释放最多的内存。
如果我们把某个进程的oom_score_adj设置为-1000（早期版本的linux oom_score的计算方法不同，因此调整adj的方法略有不同）,那么这个进程的oom_score就会永远为0，也就是说这个进程永远不会被oom killer杀死。这也是我们保护某个进程，不让oom killer杀掉的主要方法。
PostgreSQL避免OOM发生方法
操作系统层：
如前面所述，主要设置以下两点：
- vm.overcommit_memory设置为2：sysctl -w vm.overcommit_memory=2
- 修改postgres进程的oom_score：echo -1000 > /proc/self/oom_score_adj
数据库层：
数据库中可以进行以下调整来降低OOM发生的可能：
- 分区表特别多, 需要注意分区的catalog cache占用大量内存（PG12之后基本可以避免，或者使用pg_pathman）
- 避免长连接，连接时间越长, 访问的元数据积累越多, 导致每个会话的私有内存较大。可以通过降低总连接数或者使用连接池
- 使用HUGEPAGE, 避免page table占用较大内存. 最终引起OOM
- 避免使用较大的work_mem或hash_mem_multiplier，优化SQL，减少hash agg、hash join的使用
诸如此类的还有很多，总的来说就是降低数据库进程的内存使用。
参考链接
https://github.com/digoal/blog/blob/master/202104/20210415_04.md
https://www.kernel.org/doc/gorman/html/understand/understand016.html