文档首页/ 云数据库 RDS/ 故障排除/ RDS for PostgreSQL/ RDS for PostgreSQL实例inodes过多导致数据库重启缓慢
更新时间:2024-09-19 GMT+08:00
分享

RDS for PostgreSQL实例inodes过多导致数据库重启缓慢

实例inodes指标值过大,常见的原因是临时文件堆积、表对象过多。这两种情况下发生异常重启时,均会拖慢启动进程。

场景一

  • 场景描述

    使用RDS for PostgreSQL数据库时,业务执行大量复杂SQL,造成临时文件堆积,内存耗尽发生OOM,数据库重启过程非常缓慢,导致业务较长时间不可用。

  • 原因分析

    由于业务执行复杂SQL,如果SQL中涉及排序、Hash join、聚合等操作,超过配置work_mem参数大小时,会生成临时文件。大量执行这样的SQL,在发生OOM时,数据库进程被OS杀掉,此时内核不会对临时文件进行清理,从而导致临时文件的堆积。过多的临时文件会拖慢数据库启动,这是因为在PostgreSQL数据库进程启动时,需要删除所有之前产生的所有临时文件,如果存在大量临时文件堆积,将导致数据库启动缓慢。

  • 解决方案

    建议业务侧优化SQL,或适当调大work_mem参数值(会增加内存占用),减少临时文件生成。

场景二

  • 场景描述

    使用RDS for PostgreSQL数据库时,业务创建了大量的表。某一时间连接数与业务量激增,数据库进程内存耗尽发生OOM,从而导致数据库重启,但重启过程非常缓慢,导致业务较长时间不可用。

  • 原因分析

    由于数据库发生了OOM进而导致进程重启,在启动时会进入故障恢复模式,这时内核进程会遍历所有表并做fsync(将os缓存内容刷新至磁盘),如果业务创建的表对象过多,在启动时便会消耗大量时间进行遍历,从而导致数据库启动缓慢,影响业务可用性。

  • 解决方案
    • 建议业务侧限制创建表的数量,单实例表数量最好不超过2万,单库表数量最好不超过4千,详见实例使用规范
    • 建议业务侧配置内存监控,必要时扩充内存规格,尽量避免OOM发生。同时关注inode数监控指标,控制创建的对象数量。

相关文档