Postgresql OOM 可能原因汇总

背景

不久前，遇到过一个问题。Postgresql 数据库主机系统触发OOM现象是数据库进程被KILL, 数据库进入crash然后restart(when restart_after_crash=on).

导致OOM的原因很多, 当然要具体情况，具体分析。从数据库层面分析内存分为共享内存(shared buffer)和私有内存(例如catalog cache,relcache等)。目前版本还不支持查看shared buufer详细使用情况(这类功能往往需要插件实现)。所以本例仅对会话私有内存占用过大进行归类。最常见的原因汇总如下, 以及对应的规避方法。

汇总

1、分区表特别多, 分区的catalog cache占用大量内存(连接会话可能会读入每个子分区的结构到catalog cache)，特别需要注意explain里面信息并不代表relcache里的信息。

2、业务使用了大量长连接, 总连接数过多,并且没有设置连接的生命周期, 连接时间越长, 连接总数越多,访问的元数据可能积累越多, 导致每个会话的私有内存非常大。
- 避免方法1: 降低应用连接到数据库的总连接数, 并且设置连接的生命周期(例如, 一个连接最多使用15分钟后自动释放)，避免出现某些连接占用大量私有内存。
- 避免方法2: 使用连接池。

3、数据库实例未使用HUGEPAGE, 导致page table占用较大内存，最终引起OOM.
- 避免方法: 检查系统是否开启HUGEPAGE，建议开启HUGEPAGE。

5、设置了较大的work_mem, 并且有大量SQL使用了hash agg或hash join, 导致内存消耗过多,当然还容易产生过多临时文件。
- 避免方法: 调小work_mem，业务层减少此类sql请求的并发量。
- 注意,可能某些版本已经支持enable_hashagg_disk, 可以开启防止内存不足时无法使用hashagg。

6、数据库有性能问题, 遇到应用程序配置的连接池上限较大, 导致同一时期向数据库请求了大量连接, 最终耗费大量内存引起OOM.
- 避免方法1: 降低应用到数据库的总连接数, 并且设置连接的生命周期(例如, 一个连接最多使用15分钟后自动释放).
- 避免方法2: 设置连接上限。
- 避免方法3: 找到低效topSQL并优化.

7、如果是分区数量导致的问题, 首先要分析是什么分区类型.
如果是hash分区, 通常一个长连接的每次SQL请求的数据定位到的分区是不同的子分区, 连接使用久了就会hold所有的子分区的元数据, 占用内存大.
如果是按时间的范围分区,, 每次SQL请求的基本上都是当前时期的子分区, 所以长连接hold的分区数量不会太多, 内存消耗问题可能性低.
- 如果是hash分区产生的内存消耗问题怎么办? 除了前面提到的6点方法, 还有2种方法,- 1、通过业务层改造减少分区数量也能减少内存消耗.- 2、业务层集成数据库的hash算法, 把和不同分区相关的数据操作分配到不同的线程, 不同的线程使用不同的数据库连接,这样每个连接只会用到某些特定的子分区, 不会导致每个连接都hold所有分区表.

总结

其实对于Postgresql 数据库，如果业务类型多为排序并发的sql为主。那么建议给数据库所在服务器分配大内存，256GB以上。因为每个session都会用到work_mem内存，如果work_mem设置为100MB，总共有2000个session上限，那么这部分内存的上限就是100*2000。这是非常恐怖的数值，当然这种极端情况很少发生。如果单个会话work_mem内存用满就会用到磁盘排序，如果io拥挤会对数据库性能有严峻考验。

综上所述，我们需要在合理范围内把服务器内存分配给数据库使用，并严格把控数据库的内存使用情况，避免内存耗尽。

审计

没错，当OOM发生后，我们可以找到一些蛛丝马迹。

由于OOM发的是KILL -9的信号，被KILL的进程根本无法记录当时正在执行的QUERY或者当时的状态。

如果我们需要在OOM后，还能找到被OOM进程当时执行的QUERY，在请求时(语句分析和计划后)就记录下它在执行什么(开启log_statement='all')，超过track_activity_query_size长度的QUERY都被截断。