云贝教育 |【技术文章】postgresql触发OOM解析

注: 本文为云贝教育 刘峰 原创，请尊重知识产权，转发请注明出处，不接受任何抄袭、演绎和未经注明出处的转载。

示例： 在一台运行着PostgreSQL数据库的Linux服务器上，如果数据库工作负载非常高，例如在短时间内执行了大量的复杂查询，或者一次性加载了很大的数据集进行处理，可能会导致数据库进程占用大量的内存。例如：

1. 大规模排序操作或哈希聚合操作，这些操作会消耗 work_mem 参数指定的内存。
2. 大量的临时表操作，这会占用 temp_buffers 参数所设定的内存区域。
3. 如果进行了大规模的数据导入或索引重建，可能消耗 maintenance_work_mem 参数设定的内存。
4. 缓冲池（buffer cache）过大，如果所有活跃的数据都尝试放入内存，可能导致整个系统内存耗尽。

当PostgreSQL进程消耗的内存超过了操作系统可分配的总量，操作系统内核的OOM Killer可能会介入，为了保护系统的稳定性，选择结束掉消耗内存最多的进程，而这很可能就是PostgreSQL数据库服务进程，从而导致数据库服务宕机。

日志示例：

在PostgreSQL的日志中，不会直接记录OOM Killer的信息，但可能会看到类似下面这样的错误提示，间接表明是因为内存不足引发的问题：

LOG: could not fork new process for connection: Cannot allocate memory

数据库调整方案：

1. 参数优化：

• **work_mem:**根据实际业务需求调整每个查询可以使用的内存大小，避免单个查询消耗过多内存。
• **temp_buffers:**设置合适的临时缓冲区数量，防止临时表操作消耗过多内存。
• **maintenance_work_mem:**为大型维护操作（如VACUUM FULL、CREATE INDEX CONCURRENTLY等）分配充足的内存，但不至于过大。
• **shared_buffers:**这是PostgreSQL用于共享内存缓冲池的大小，应根据服务器总内存和并发连接数适量调整，但不要占用全部内存。

2. 监控与报警：

• 使用系统监控工具（如Prometheus、Grafana配合PostgreSQL exporter）实时监控数据库内存使用情况。
• 设置阈值报警，当内存接近满载时提前预警，以便及时手动干预或自动调度清理或优化操作。

3. 查询优化：

• 分析慢查询日志，找出消耗内存多的查询语句，通过重构查询、添加索引等方式优化查询效率和内存使用。
• 避免一次性加载大表或执行可能导致内存爆炸的复杂运算。

4. 资源管理：

• 在容器化部署环境中，给PostgreSQL容器分配适当的内存限制，并留有足够的余量给操作系统和其他服务。
• 在物理服务器上，确保操作系统本身有足够的内存，同时为PostgreSQL分配合理的内存上限。

5. 定期维护与清理：

• 定期进行 vacuum 和 analyze 操作，尤其是对于频繁更新的大表，可以有效释放内存和磁盘空间。
• 清理不再需要的索引和无用的大数据集。

6. 硬件扩容：

• 如必要，增加服务器的RAM，以适应更高的内存需求。

总结来说，解决PostgreSQL触发的操作系统OOM问题需要综合考虑系统配置、数据库参数优化、查询性能优化和系统资源的有效管理等多个方面，同时也需要良好的监控机制来预防潜在的风险

操作系统层面的调整方案：

1. 监控与告警：

• 安装系统监控工具，例如Nagios、Zabbix等，设置针对系统内存使用情况的告警阈值，当系统内存即将耗尽时，能够及时发送通知，提醒管理员进行干预。

2. 调整内存分配策略：

调整Linux内核的虚拟内存过载提交策略，通过修改 /proc/sys/vm/overcommit_memory 文件内容：

• 将其设置为0表示保守的过载提交策略，系统会尝试预测是否有足够的内存满足新的内存分配请求。
• 设置为1表示总是答应内存分配请求，但在内存耗尽时，可能会触发OOM Killer。
• 设置为2表示根据当前可用交换空间来决定是否答应内存分配请求。

3. 调整交换空间大小：

• 如果物理内存不足，可以适当增加交换空间（Swap Space），但要注意交换空间的速度远低于物理内存，只能作为临时应急措施，长期而言应增加物理内存或优化应用内存使用。
• 使用 swapon 或在 /etc/fstab 中设置，确保交换分区足够应对突发的内存需求。

4. OOM Killer调整：

1. 调整OOM Killer的决策策略，通过编辑 /proc/<pid>/oom_score_adj（或者对于较新内核 /proc/<pid>/oom_score_adj）文件，可以改变特定进程在OOM Killer决策时的得分，避免重要的服务进程（如PostgreSQL）被优先杀死。
2. 设置 sysctl vm.panic_on_oom=0 可以防止系统在触发OOM时直接panic，改为尝试触发OOM Killer。

5. 内存资源限制：

1. 在容器环境下，可以通过 Docker 的 -m 或 --memory 参数限制单个容器的最大内存使用量，避免单个容器占用所有系统内存导致其他进程OOM。
2. 对于非容器环境，可以考虑使用cgroups限制特定进程组的内存使用上限。

6. 系统层面的内存优化：

1. 减少系统服务的内存开销，例如禁用不必要的服务，或者调整它们的内存使用参数。
2. 定期检查系统内存泄漏，使用 top、htop、free、smem 等工具监控内存使用情况，发现内存消耗异常的进程应及时处理。

总的来说，操作系统层面的调整主要是通过对内存资源进行合理分配、设置告警阈值、优化内存分配策略以及限制特定进程的内存使用，结合应用层面的优化共同解决PostgreSQL触发的操作系统OOM问题。同时，还需要密切关注系统总体内存使用情况，确保整体系统的稳定运行。