多个网站 支付宝接口,临淄做网站,关键词优化如何,网站开发用什么编辑器好点开头还是介绍一下群#xff0c;如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题#xff0c;有需求都可以加群群内有各大数据库行业大咖#xff0c;CTO#xff0c;可以解决你的问题。加群请联系 liuaustin3 #xff0c;在新加的朋友… 开头还是介绍一下群如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题有需求都可以加群群内有各大数据库行业大咖CTO可以解决你的问题。加群请联系 liuaustin3 在新加的朋友会分到2群共1720人左右 1 2 3 45 另欢迎 OpenGauss GAUSSDB的技术人员加入 PostgreSQL 的内容之前写上百篇这里打算开一个系列叫PostgreSQL难搞的事情主要针对PostgreSQL中经常被问及的问题和一些导致这些问题深层次的原因的一个主题。这次的主题从PostgreSQL的vacuum 开始 说到Vacuum 属于是几家欢喜几家愁的一般发愁的都是那些PostgreSQL 业务繁忙的大库并且经常出现业务高峰期的一些系统性能的波动。但大部分人都只关注Vacuum, autovacuum 而忽略了一些为什么会产生这样动作的原因同时不少人对 aggressive vacuum 的是什么不了解导致vacuum 和 aggressive vacuum 的问题搞不清最终导致严重的问题。 首先vacuum 的由来这个问题需要反复的说在我们进行多版本控制,MVCC multiversion concurrency control ,是产生PG vacuum的根源 mvcc主要目的就是提供在数据库访问中可以进行并发访问并发访问则需要对于事务中的数据提供同一行数据在不同时间中访问中的版本信息而这些信息是集中式还是分散式是两种数据库设计的不同。 在PostgreSQL中我们使用了分散式也就是将所有的行的版本信息驻留在我们的数据表内基于这样的处理方式导致后续这些失效的版本行信息需要进行清理而清理这些行的信息的过程称为vacuum,相对应的我们会有 vacuum 和 autovacuum的命令和相关的过程来进行相关的工作而基于这样的形成方式导致PostgreSQL 应对这部分工作并产生了一套与其他数据库截然相反的工作。 在工作中我们大概率会遇到以下的一些问题 1 回收不及时触发数据库回卷导致触发aggresive vaccum,或最终导致freezing boom 触发单用户模式。 2 触发Autovacuum进行回收与系统正在进行高耗能操作撞车导致系统性能出现瓶颈影响正常业务 3 关于vacuum的命令和参数多每个版本都有新的东西的加入变化多部分版本对于命令参数进行了改变并且参数的细致程度高大部分人无法进行有效配置和调配 所以基于这些问题我们需要分几期来说这个问题整体系统化的梳理基于数据库设计产生的一些在PostgreSQL中的特殊的需求的问题。 本期是这个系列的第一篇所以我们先从问题的起源来详细说一说这里我们看下图下面两个图清晰的展示了数据表中某行的数据产生新一个行版本和老版本行共存的过程以及访问中通过老的行指向新的行的过程等。 必然在上一个版本的行在所有事务中都成为历史行后会成为死行死行就相当于其他数据库中UNDO 中需要被清理的数据信息。 基于MVCC的形成PostgreSQL的每行上都会对于他是那个数据库库事务的归属进行标记在这样的情况下标记每行属于那个事务的数字txid也有使用耗费光的情况基于这个数字的大小为2的32次方那么在回收这些txid 号的情况下很有可能由于一些情况而无法对这些txid的号进行收回而长时间无法收回这些txid的情况就会导致数据库产生 aggressive vacuum ,aggressive vaccum 。 导致aggressive vacuum 后最大的问题是aggressive vacuum中的扫描工作普通的vacuum本身并不会对数据表中每页的数据进行扫描而aggressive vacuum 则是针对未冻结的数据页面全部扫描扫描中会导致大表较长时间在进行整体的页面扫描扫描期间的CPU 和IO 均会为此项工作服务同时还会导致长时间针对这张表无法进行DDL操作。所以我们在工作中都在尽力的避免发生 aggressive vacuum 的工作。 下面我们通过一个列子来进行展示我们找到一张表其中我们计算出他的相关的age 是 478 postgres# SELECT c.oid::regclass as table_name,greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
postgres-# FROM pg_class c
postgres-# LEFT JOIN pg_class t ON c.reltoastrelid t.oid
postgres-# WHERE c.relkind IN (r, m) and c.oid::regclass::varchar time_test;table_name | age
-----------------time_test | 478
(1 row) 然后我们针对这张表进行vacuum 的操作然后我们在观察相关的这张表的age postgres# vacuum verbose time_test;
INFO: vacuuming public.time_test
INFO: table time_test: found 0 removable, 1 nonremovable row versions in 1 out of 1 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 878875
0 pages removed.
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres# 在我们对表进行vacuum后发现表的age还是 478并未有任何的变化。在我们改变命令后针对这个表进行freeze 的操作后我们在观察age的部分已经变为0. postgres# vacuum freeze verbose time_test;
INFO: aggressively vacuuming public.time_test
INFO: table time_test: found 0 removable, 1 nonremovable row versions in 1 out of 1 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 878875
0 pages removed.
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s.
VACUUM
postgres# SELECT c.oid::regclass as table_name,greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid t.oid
WHERE c.relkind IN (r, m) and c.oid::regclass::varchar time_test;table_name | age
-----------------time_test | 0
(1 row) postgres# SELECT
postgres-# oid::regclass::text AS table,
postgres-# age(relfrozenxid) AS xid_age,
postgres-# mxid_age(relminmxid) AS mxid_age,
postgres-# least(
postgres(# (SELECT setting::int
postgres(# FROM pg_settings
postgres(# WHERE name autovacuum_freeze_max_age) - age(relfrozenxid),
postgres(# (SELECT setting::int
postgres(# FROM pg_settings
postgres(# WHERE name autovacuum_multixact_freeze_max_age) - mxid_age(relminmxid)
postgres(# ) AS tx_before_wraparound_vacuum,
postgres-# pg_size_pretty(pg_total_relation_size(oid)) AS size,
postgres-# pg_stat_get_last_autovacuum_time(oid) AS last_autovacuum
postgres-# FROM pg_class
postgres-# WHERE not (relfrozenxid 0)
postgres-# AND oid 16384
postgres-# ORDER BY tx_before_wraparound_vacuum;table | xid_age | mxid_age | tx_before_wraparound_vacuum | size | last_aut
-------------------------------------------------------------------------------------------test_t | 289 | 0 | 199999711 | 127 MB | collates | 253 | 0 | 199999747 | 56 kB | test_table | 234 | 0 | 199999766 | 40 kB | xcc.xcc | 210 | 0 | 199999790 | 0 bytes | pgbench_history | 14 | 0 | 199999986 | 0 bytes | pgbench_accounts | 14 | 0 | 199999986 | 13 GB | pgbench_branches | 14 | 0 | 199999986 | 112 kB | pgbench_tellers | 14 | 0 | 199999986 | 712 kB | bank | 3 | 0 | 199999997 | 40 kB | dba_autovacuum_table | 0 | 0 | 200000000 | 8192 bytes | time_test | 0 | 0 | 200000000 | 56 kB |
(11 rows) 上面的脚本可以方便的查看当前的数据库中表中的AGE 以及发生回卷的计数器的数值。 在PostgreSQL 16 中针对vaccumdb 命令有了一些变化我们把PG14 和PG16 的vacuumdb 我们清晰的看到有四个部分是不同的 1 --buffer-usage-limitSIZE 2 --no-process-main 3 -n, --schemaPATTERN 4 -N, --exclude-schemaPATTERN 具体上我们可以对1 2 两个部分进行更细的研究 buffer-usage-limit 命令主要的意义,主要的目的还是针对具有大内存的主机在进行vaccum的过程中可以给与更多的内存尽量对于大表进行快速有效的vacuum。相关范围在不开启和 128KB - 16G 之间进行设置。 --no-process-main 这个主要添加的参数是为了不进行表的vacuum 只对表中的toast进行vacuum。 参考https://www.postgresql.org/message-id/08930c0b541700a5264e5fbf3a685f5aoss.nttdata.com
