暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

PostgreSQL 错了被别人指出,是人生幸事 vacuum 操作修正

问题是这样的,回答一个关于vacuum操作的问题的时候,由于学艺不精,知识不扎实,选择了错误的答案,有幸于马上有人指出错误。才不至于将错误的理解延续,所以的写一篇来将错误的理解纠正,并加深印象。

问题1 为什么要vacuum 
postgresql 数据库并没有使用我们熟悉的类似于ORALCE ,MYSQL的redo,undo的数据库架构,PG独有的架构优点很多,但我们也必须面对部分的问题,在更新或删除PostgreSQL表中的行,会留下死行。Vacuum的作用可以去掉它们,这样空间就可以重复利用了。如果一个表没有被清空,它就会变得臃肿,这就会浪费磁盘空间并降低顺序表扫描的速度(在较小的范围内,还会降低索引扫描的速度)。

问题2 一般我们怎么处理

一般的情况下,我们通过上面的语句可以检测我们的autovacuum到底有没有执行,并且当前各个表的n_dead_tupd的情况如何。以及最近一次的 autovaccum 的情况。


问题 3 autovacuum 不管用怎么办?

事实上是的,如果autovacuum都百分之百的不出问题,那就没有这个话题了

所以有的时候,我们就需要vacuum 来处理一些问题

从下图可以看出,在执行了vacuum 后刚才还15个 dead tuple,已经变成了0

问题 4  vacuum  autovacuum  vacuum full 之间有什么不同


autovacuum 

autovaccum 的主要功能自动执行vacuum 和 Analyze命令,autovacuum检测表有大量的inserted ,updated , deleted操作,另外还需要打开track_counts,否则autovacuum 将不能被正常使用。

autovacuum 实际上是由多个进程组成,主线程autovacuum 会在何时地时间调用,这里与 autovaccum_naptime 以及PG 如果有多个数据库地情况下,还和autovacuum_max_worker有关。每个worker process将检查每一个数据库表并且执行vacuum 和 分析,这里官方文档中提及,当数据库中有大表情况下,很可能一个数据库一个autovacuum worker process 忙于处理大表,而让其表无法接受到autovacuum ,并且在一个数据库中可以有多少work process是没有限制的,work process 确实试图避免重复其他process已经完成的工作,运行的worker的数量并不计入max_connections。



Vacuum


真空的主要工作是回收被标记为dead 的元组占用的存储空间。回收的存储空间不会返回给操作系统,而是在同一个页面中进行整理,因此将来在同一个表中插入数据时可以重用它们。当对特定表执行真空操作时,可以同时对同一表执行其他读/写操作,因为对特定表不执行独占锁。如果没有指定表名,将对数据库的所有表执行VACUUM。

Vacuum 到当地做了什么是一个需要被了解的地方,之前也是迷迷糊糊

下面列一下

1 扫描所有表,或者特殊表,得到dead tuples

2 如果需要会固化需要清理的dead tuples

3 清理与dead tuples有关的index tuple

4 清理页面中的dead tuples 并将清理后的空间释放

5 更新对应表的FSM 和 VM 文件

6 更新相关的系统表


从上面看VACUUM 操作是非常耗费资源的,这也是其他数据库专家诟病POSTGRESQL 的一个地方,这里我们尽量不要去扫描所有的页,所以VM的存在是很必要的。


FULL Vacuum

从上面的解释看,Vacuum 已经满足了大部分的需求,那Full vacuum的操作的意义是什么,尽管VACUUM删除了所有无效的元组并对页面进行碎片整理以供将来使用,但它并不能帮助减少表的总体存储,因为实际上并没有将空间释放给操作系统。其实其他数据库也有类似的空间释放的方式,但实话是不怎么常用,当然这和他们的数据库原理有关,而放到pg里面可能由于本身的原理结构,这样的操作就被重视起来。


不愿意使用full vacuum 的原因是,他需要对系统有独占的权利

FULL Vacuum 到当地做了什么

1 对于表使用了独占锁 exclusive lock

2 创建一个并行的空的存储文件

3 将目前的标记为存活的tuples(行)拷贝到了新的存储中(其实就是新的物理文件)

4  在将原有的数据都拷贝后,开始释放原有的存储数据的文件

5  释放独占锁


其实上面的full  vacuum 的操作让我想起 mysql 的  

OPTIMIZE TABLE

ALTER TABLE table_name ENGINE = Innodb;

原理与full vacuum 基本上没有什么两样,或许人们已经习惯了 MYSQL 的曾经,但面对PG的类似的这样的操作和问题,就不那么淡定了,或许在心里暗暗的认为PG 这么高大上的数据库不应该存在这样问题。


其实反观商业数据库也有类似的问题,例如去shrink 一个 mdf 文件,ndf 文件,那也和死了一样的恐怖。


回到PG ,我们可以使用下面的命令来查看某个表的free space

SELECT count(*) as npages, round(100 * avg(avail)/8192 ,2) as average_freespace_ratio FROM pg_freespace('test1000');


这告诉你这些空间可以被重用,那到底你要不要 full vacuum 你来自己决定,难道磁盘空间添加的是一件很难的事情吗?


最后,感谢那些指正你错误的人,因为夸奖不能让你进步,友善的指责和指正,才是你变得强大的力量,thanks 


vacuum 命令不会更新统计信息,不会忘记




I Love PG

关于我们

中国开源软件推进联盟PostgreSQL分会(简称:PG分会)于2017年成立,由国内多家PG生态企业所共同发起,业务上接受工信部产业发展研究院指导。PG分会致力于构建PG产业生态,推动PG产学研用发展,是国内一家PG行业协会组织。



欢迎投稿

做你的舞台,show出自己的才华 。

投稿邮箱:partner@postgresqlchina.com

                               

                                 ——愿能安放你不羁的灵魂


技术文章精彩回顾




PostgreSQL学习的九层宝塔
PostgreSQL职业发展与学习攻略
搞懂PostgreSQL数据库透明数据加密之加密算法介绍
一文读懂PostgreSQL-12分区表
PostgreSQL源码学习之:RegularLock
Postgresql源码学习之词法和语法分析
PostgreSQL buffer管理
最佳实践—PG数据库系统表空间重建
PostgreSQL V12中的流复制配置
2019,年度数据库舍 PostgreSQL 其谁?
PostgreSQL使用分片(sharding)实现水平可扩展性
一文搞懂PostgreSQL物化视图
PostgreSQL原理解析之:PostgreSQL备机是否做checkpoint
PostgreSQL复制技术概述

PG活动精彩回顾




见证精彩|PostgresConf.CN2019大会盛大开幕
PostgresConf.CN2019大会DAY2|三大分论坛,精彩不断
PostgresConf.CN2019培训日|爆满!Training Day现场速递!
「PCC-Training Day」培训日Day2圆满结束,PCC2019完美收官
创建PG全球生态!PostgresConf.CN2019大会盛大召开
首站起航!2019“让PG‘象’前行”上海站成功举行
走进蓉城丨2019“让PG‘象’前行”成都站成功举行
中国PG象牙塔计划发布,首批合作高校授牌仪式在天津举行
PostgreSQL实训基地落户沈阳航空航天大学和渤海大学,高校数据库课改正当时
群英论道聚北京,共话PostgreSQL
相聚巴厘岛| PG Conf.Asia 2019  DAY0、DAY1简报
相知巴厘岛| PG Conf.Asia 2019 DAY2简报
相惜巴厘岛| PG Conf.Asia 2019 DAY3简报
独家|硅谷Postgres大会简报
全球规模最大的PostgreSQL会议等你来!

PG培训认证精彩回顾




关于中国PostgreSQL培训认证,你想知道的都在这里!
首批中国PGCA培训圆满结束,首批认证考试将于10月18日和20日举行!
中国首批PGCA认证考试圆满结束,203位考生成功获得认证!
中国第二批PGCA认证考试圆满结束,115位考生喜获认证!
请查收:中国首批PGCA证书!
重要通知:三方共建,中国PostgreSQL认证权威升级!
一场考试迎新年 | 12月28日,首次PGCE中级认证考试开考!
近500人参与!首次PGCE中级、第三批次PGCA初级认证考试落幕!


最后修改时间:2020-03-20 15:09:37
文章转载自开源软件联盟PostgreSQL分会,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论