本文主要是介绍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 命令不会更新统计信息,不会忘记。
这篇关于PostgreSQL 错了被别人指出,是人生幸事 vacuum 操作修正的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!