首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

Pg数据库日常维护操作指南

本文主要用来记述pg数据库的相关操作和异常排查指南,继上一篇博客之后,异常的频繁更新,导致死亡元组指数级增长之后,空间占用也成倍增长,逻辑问题导致了数据库问题,但细想之下也发现,当pg在面对海量数据的更新删除之后,频繁的autovacuum会导致数据库大量的I/O,完了又会影响其他进程,就参数配置来看,还是有蛮多优化的空间的,毕竟空间和时间是两个相生相克的关系。就目前的默认的配置来看,手动标记60w数据执行vacuum标记清理花了6分钟,直接清空死亡元组也差不多这个时间,当空间膨胀到300g的时候数据量达到140w,vacuum已经有点吃不消了执行了半个小时也没有看到执行结束,至少在频繁更新的情况下,可见vacuum还是有他的局限性,就像官网提示的:Plain VACUUM may not be satisfactory when a table contains large numbers of dead row versions as a result of massive update or delete activity. 而且默认配置的的自动间隔是1分钟,我觉得这里面有很大的优化空间,尤其是海量数据频繁更新和删除的时候,当autovacuum的执行时间超过1分钟之后,就需要注意系统的死亡元组数量了,类似于当我打扫垃圾的速度低于产生垃圾的速度此时垃圾只会越来越多,当然这是在大数据量特定频繁更新和删除场景的情况下,结合相关的配置产生的一种思考。 需要注意的配置主要有autovacuum_max_workers可以根据cpu核心数配置,autovacuum_work_mem工作内存和vacuum_scale_factor规模因子,

02
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    openGauss中的最大可用模式为什么PG不做?

    至于pg为什么不做这个功能我也想了很久,下面是我自己的一点猜测。pg是个追求完美主义的数据库,他从架构设计层面就会考虑如何做到完美,比如说他不用主流数据库都在使用的undo,我猜测这个原因是因为,使用undo有一个问题,undo空间不管是文件系统还是表空间都是有大小限制的,而数据库未提交的事务信息可能是无限大的,这样数据的前镜像总有可能将undo空间撑爆掉,这样就需要清理旧的undo段,如果需要查询的undo前镜像备清理了,数据库就会跑出错误,这就是oracle中经典的snapshot too old报错。所以pg摒弃了这种模式,因为他觉得必须要提供给用户一个需要的数据一定能查到的数据库,而不是本该能查到的数据被无端清理掉了,所以pg使用了多数据版本来解决这个问题,将前镜像的真实数据放在数据文件中,真正确保没有事务可能再去访问该数据时才进行清理。当然这样也带来膨胀的问题,这其实也是pg最遭人诟病的问题。

    02
    领券