PostgreSQL VACUUM 之深入淺出 (五)


AUTOVACUUM to prevent wraparound

autovacuum_freeze_max_age 是 AUTOVACUUM 最不常用的參數,也基本不需要優化,但卻是 AUTOVACUUM 最重要的一個參數,因為它與 wraparound 有關,即使 AUTOVACUUM 關閉,達到這個閾值,也會強制觸發 AUTOVACUUM ,可見它有多重要。

#autovacuum_freeze_max_age = 200000000  # maximum XID age before forced vacuum
                                        # (change requires restart)

首先打開 AUTOVACUUM。為了方便測試,將 autovacuum_freeze_max_age 設置為其最小值。

autovacuum_freeze_max_age = 100000

正常情況是達不到 autovacuum_freeze_max_age 閾值的,因為還沒有達到這個閾值,就觸發了 AUTOVACUUM。為了能測試到這個閾值,人工創建一條 idle in transaction,以阻塞正常的 AUTOVACUUM。

alvindb=# BEGIN;
BEGIN
alvindb=# SELECT txid_current();
 txid_current
--------------
     15200695
(1 row)

alvindb=# UPDATE alvin.tb_test_vacuum SET test_num = test_num WHERE test_num = 1;
UPDATE 1

查到 idle in transaction 如下,可以看到其 backend_xid 為 15200695:

postgres=# SELECT * FROM pg_stat_activity WHERE state = 'idle in transaction';
-[ RECORD 1 ]----+------------------------------
datid            | 37509
datname          | alvindb
pid              | 28497
usesysid         | 10
usename          | postgres
application_name | psql
client_addr      | 
client_hostname  | 
client_port      | -1
backend_start    | 2021-11-13 23:18:33.480814+08
xact_start       | 2021-11-13 23:19:45.288275+08
query_start      | 2021-11-13 23:19:58.133248+08
state_change     | 2021-11-13 23:19:58.133412+08
wait_event_type  | Client
wait_event       | ClientRead
state            | idle in transaction
backend_xid      | 15200695
backend_xmin     | 
query            | SELECT txid_current();
backend_type     | client backend

不斷更新表,使其達到閾值。

alvindb=# SELECT c.relname, c.relfrozenxid,age(c.relfrozenxid) FROM pg_class c WHERE relname = 'pgbench_accounts';
     relname      | relfrozenxid |  age   
------------------+--------------+--------
 pgbench_accounts |     15250696 | 100000
(1 row)

此時修改最后一條數據,使表的 age 超過閾值。

alvindb=# SELECT c.relname, age(c.relfrozenxid) FROM pg_class c WHERE relname = 'pgbench_accounts';
     relname      |  age   
------------------+--------
 pgbench_accounts | 100001
(1 row)

可以看到,此時已觸發 aggressive vacuum to prevent wraparound。

其 query 為 VACUUM public.pgbench_accounts (to prevent wraparound),並且 backend_xmin 為 15200695。

-[ RECORD 1 ]----+-------------------------------------------------------------------
datid            | 37509
datname          | alvindb
pid              | 30288
usesysid         | 
usename          | 
application_name | 
client_addr      | 
client_hostname  | 
client_port      | 
backend_start    | 2021-11-13 23:30:39.767723+08
xact_start       | 2021-11-13 23:30:39.788839+08
query_start      | 2021-11-13 23:30:39.788839+08
state_change     | 2021-11-13 23:30:39.788839+08
wait_event_type  | 
wait_event       | 
state            | active
backend_xid      | 
backend_xmin     | 15200695
query            | autovacuum: VACUUM public.pgbench_accounts (to prevent wraparound)
backend_type     | autovacuum worker

從 PostgreSQL 日志中可以看到觸發的 automatic aggressive vacuum。

[    2021-11-13 23:30:40323 CST 30288 618fda1f.7650 3 6/72694 0]LOG:  automatic aggressive vacuum of table "alvindb.public.pgbench_accounts": index scans: 1
        pages: 0 removed, 404 remain, 0 skipped due to pins, 0 skipped frozen
        tuples: 3 removed, 100000 remain, 0 are dead but not yet removable, oldest xmin: 15200695
        buffer usage: 438 hits, 480 misses, 412 dirtied
        avg read rate: 28.065 MB/s, avg write rate: 24.089 MB/s
        system usage: CPU: user: 0.02 s, system: 0.03 s, elapsed: 0.53 s
[    2021-11-13 23:30:40.334 CST 30288 618fda1f.7650 4 6/72696 0]WARNING:  oldest xmin is far in the past

所以,如果一旦發現 aggressive vacuum (to prevent wraparound),需要格外重視,檢查是否出現類似 idle in transaction 等異常情況。

尤其是 PostgreSQL 9.6 之前,還沒有參數 idle_in_transaction_session_timeout(since PostgreSQL 9.6) 的版本,需要手動 terminate idle in transaction。或 PostgreSQL 9.6 之后,但未設置該參數。

總結

本文由淺入深,一步一步演示了如何精准觸發 AUTO VACUUM,並就各個參數如何調優進行了詳細的測試。性能提高同時,也注意是否出現主從延遲、CPU、load、IO、網絡流量及 archive 等問題。

公眾號

關注 DBA Daily 公眾號,第一時間收到文章的更新。
通過一線 DBA 的日常工作,學習實用數據庫技術干貨!

公眾號優質文章推薦

PostgreSQL VACUUM 之深入淺出

華山論劍之 PostgreSQL sequence

[PG Upgrade Series] Extract Epoch Trap

[PG Upgrade Series] Toast Dump Error

GitLab supports only PostgreSQL now

MySQL or PostgreSQL?

PostgreSQL hstore Insight

ReIndex 失敗原因調查

PG 數據導入 Hive 亂碼問題調查

PostGIS 擴展創建失敗原因調查


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM