陈老师:1415968548 郑老师:2735197625 乐老师:354331153
客服热线:
19941464235/19906632509(微信同号)

客服微信

【PostgreSQL】postgresql触发OOM解析

作者:炎燚小寶
发布时间:2024-04-29 13:40
浏览量:91

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


示例: 在一台运行着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 文件内容:




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问题。同时,还需要密切关注系统总体内存使用情况,确保整体系统的稳定运行。



想了解更多PG相关的学习资料(技术文章和视频),可以微信公众号或B站搜索《云贝教育》,免费获取。

想了解更多PG相关的学习资料(技术文章和视频),可以微信公众号或B站搜索《云贝教育》,免费获取。

想了解更多PG相关的学习资料(技术文章和视频),可以微信公众号或B站搜索《云贝教育》,免费获取。


另外需要学习资料 的同学,可以添加联系方式:(同V) 陈老师 199-4146-4235 / 郑老师 199-0663-2509 / 蕾老师199-0663-5786,我们会持续更新学习视频。