【PostgreSQL】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调整:

• 调整OOM Killer的决策策略,通过编辑 /proc//oom_score_adj(或者对于较新内核 /proc//oom_score_adj)文件,可以改变特定进程在OOM Killer决策时的得分,避免重要的服务进程(如PostgreSQL)被优先杀死。

• 设置 sysctl vm.panic_on_oom=0 可以防止系统在触发OOM时直接panic,改为尝试触发OOM Killer。

5. 内存资源限制:

• 在容器环境下,可以通过 Docker 的 -m 或 --memory 参数限制单个容器的最大内存使用量,避免单个容器占用所有系统内存导致其他进程OOM。

• 对于非容器环境,可以考虑使用cgroups限制特定进程组的内存使用上限。

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

• 减少系统服务的内存开销,例如禁用不必要的服务,或者调整它们的内存使用参数。

• 定期检查系统内存泄漏,使用 top、htop、free、smem 等工具监控内存使用情况,发现内存消耗异常的进程应及时处理。

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

相关推荐
数字扫地僧1 分钟前
WebLogic 版本升级的注意事项与流程
数据库
Viktor_Ye18 分钟前
高效集成易快报与金蝶应付单的方案
java·前端·数据库
努力算法的小明1 小时前
SQL 复杂查询
数据库·sql
斗-匕1 小时前
MySQL 三大日志详解
数据库·mysql·oracle
代码中の快捷键1 小时前
MySQL数据库存储引擎
数据库·mysql
只因在人海中多看了你一眼1 小时前
数据库体系
数据库
尘浮生1 小时前
Java项目实战II基于微信小程序的电影院买票选座系统(开发文档+数据库+源码)
java·开发语言·数据库·微信小程序·小程序·maven·intellij-idea
六月闻君2 小时前
MySQL 报错:1137 - Can‘t reopen table
数据库·mysql
SelectDB技术团队2 小时前
兼顾高性能与低成本,浅析 Apache Doris 异步物化视图原理及典型场景
大数据·数据库·数据仓库·数据分析·doris
inventecsh2 小时前
mongodb基础操作
数据库·mongodb