在 Amazon RDS for PostgreSQL 上使用 PostgreSQL 自動資料清理

強烈建議您使用自動資料清理功能，以維護 PostgreSQL 資料庫執行個體的運作狀態。自動資料清理會自動啟動 VACUUM 和 ANALYZE 指令。此功能會檢查含有大量輸入、更新或刪除元組的資料表。完成檢查後，即會透過從 PostgreSQL 資料庫移除已淘汰的資料或元組回收儲存空間。

預設情況下，使用任何預設 PostgreSQL 資料庫參數群組建立的Amazon RDS for PostgreSQL 資料庫執行個體上，都開啟了自動資料清理功能。其中包括 default.postgres10、default.postgres11，以及其他版本。所有預設的 PostgreSQL 資料庫參數群組都有設為 1 的 rds.adaptive_autovacuum 參數，因此啟用了該功能。預設情況下，還會設定與自動資料清理功能相關聯的其他組態參數。因為這些預設值相當泛用，針對特定的工作負載調校與自動資料清理功能相關聯的某些參數，對您會有所幫助。

接下來，您可以找到更多有關自動資料清理功能以及如何在您的 RDS for PostgreSQL 資料庫執行個體上調校該功能一些參數的資訊。如需高層級資訊，請參閱 使用 PostgreSQL 的最佳實務。

配置自動資料清理的記憶體

maintenance_work_mem 參數是影響自動資料清理效能的最重要參數之一。此參數可決定您為自動資料清理配置多少記憶體，其會用來掃描資料庫資料表，以及保存即將清理的所有資料列 ID。如果您將 maintenance_work_mem 參數值設得太低，則清理程序可能必須掃描資料表多次才能完成其工作。多次的掃描可能會對效能產生負面影響。

進行計算以決定 maintenance_work_mem 參數值時，請記住兩件事：

• 此參數的預設單位為 kilobytes (KB)。

• maintenance_work_mem 參數會搭配 autovacuum_max_workers 參數運作。如果您有許多小型資料表，請配置較多 autovacuum_max_workers 和較少 maintenance_work_mem。如果您有大型資料表 (假設大於 100 GB)，請配置較多記憶體和較少背景工作程序。您必須配置足夠的記憶體，才能在最大的資料表上順利執行作業。每個 autovacuum_max_workers 可以使用您配置的記憶體。因此，請確保工作者程序與記憶體的組合等於您想要配置的總記憶體。

一般而言，針對大型主機，將 maintenance_work_mem 參數設定為介於 1 與 2 GB 之間的值 (介於 1,048,576 與 2,097,152 KB 之間)。針對極大型主機，將此參數設定為介於 2 與 4 GB 之間的值 (介於 2,097,152 與 4,194,304 KB 之間)。您為此參數設定的值會視工作負載而定。Amazon RDS 已更新此參數的預設值 (以 KB 為單位)，計算方式如下。

GREATEST({DBInstanceClassMemory/63963136*1024},65536).

降低交易 ID 包圍的可能性

在一些狀況中，自動資料清理相關的參數群組設定可能不夠積極以防止交易 ID 包圍。若要解決此問題，RDS for PostgreSQL 提供自動調整自動資料清理參數值的機制。自動資料清理參數彈性調校 是 RDS for PostgreSQL 的功能。PostgreSQL 文件中有詳細的 交易 ID 包圍 的說明。

預設開啟 RDS for PostgreSQL 執行個體的自動資料清理參數彈性調校功能，且動態參數 rds.adaptive_autovacuum 設定為 ON (開啟)。我們強烈建議您開啟此選項。不過，若要關閉參數彈性調校功能，請將參數 rds.adaptive_autovacuum 設定為 0 或 OFF (關閉)。

Amazon RDS 調校自動資料清理參數時，交易 ID 迴繞仍可能發生。我們建議您為交易 ID 環繞實作 Amazon CloudWatch 警示。如需詳細資訊，請參閱 AWS 資料庫部落格文章 Implement an early warning system for transaction ID wraparound in RDS for PostgreSQL (針對 RDS for PostgreSQL 中的交易 ID 迴繞實作預警系統)。

開啟自適應自動真空參數調整後，Amazon RDS 會在 CloudWatch 指標MaximumUsedTransactionIDs達到參數值或 500,000,000 (以較大者為準) 時開始調整自動真空autovacuum_freeze_max_age參數。

如果資料表繼續有交易 ID 包圍的趨勢，則 Amazon RDS 會繼續調整自動資料清理的參數。每次調整都提供更多自動資料清理的資源以避免包圍。Amazon RDS 會更新下列自動資料清理相關參數：

• autovacuum_vacuum_cost_delay

• autovacuum_vacuum_cost_limit

• autovacuum_work_mem

• autovacuum_naptime

RDS 只會在新的值能夠使自動資料清理更為積極時修改這些參數。參數在資料庫執行個體上的記憶體中修改。參數群組中的值不會變更。若要檢視目前的使用中記憶體設定，請使用 PostgreSQL SHOW (顯示) SQL 指令。

當 Amazon RDS 修改任何自動資料清理參數時，即會對受影響的資料庫執行個體產生事件。此事件會顯示在 AWS Management Console 上，也會透過 Amazon RDS API 顯示。指MaximumUsedTransactionIDs CloudWatch 標返回低於閾值後，Amazon RDS 會將記憶體中的自動真空相關參數重設回參數群組中指定的值。系統隨即會產生與此變更相對應的另一個事件。

判斷資料庫中的資料表是否需要清理

您可以使用以下查詢可用來顯示資料庫中未清理的交易數目。資料庫 datfrozenxid 列的 pg_database 欄是顯示於該資料庫正常交易 ID 的下線。此欄位是資料庫內每個資料表 relfrozenxid 最小的值。

SELECT datname, age(datfrozenxid) FROM pg_database ORDER BY age(datfrozenxid) desc limit 20;

例如，執行上述查詢的結果可能如下所示。

datname    | age
mydb       | 1771757888
template0  | 1721757888
template1  | 1721757888
rdsadmin   | 1694008527
postgres   | 1693881061
(5 rows)  

當交易 ID 包圍的存留期觸及 20 億，則會發生交易 ID 包圍 (XID)，且資料庫將變成唯獨狀態。您可使用此查詢來產生指標且一天執行數次。根據預設，自動資料清理已將交易的存留期設定為不超過 200,000,000 (autovacuum_freeze_max_age)。

範例監視策略可能如下所示：

• 設定 autovacuum_freeze_max_age 值到 2 億交易數目

• 如果資料表達到 5 億的未清理交易，則觸發低安全性警報。這並非不合理的值，但可以表示該自動資料清理並未保持啟動狀態。

• 如果資料表存留達到 10 億，這應視為採取動作的警報。一般而言，您會基於效能理由，而想讓存留期比較接近 autovacuum_freeze_max_age。我們建議您使用下列建議調查。

• 如果資料表達到 15 億的未清理交易，則觸發高安全性警報。視資料庫使用交易的速度而定，此警報可指出系統來不及執行自動資料清理。在此情況下，我們建議您立即解決此問題。

如果資料表不斷違反這些閾值，請進一步修改自動資料清理參數。依預設，手動使用 VACUUM (已停用或以成本為基礎的延遲) 比使用預設自動資料清理更積極，但總體上對系統的干擾也更加嚴重。

我們建議下列作法：

• 請注意並開啟監控機制，如此您才會注意最舊交易的存留期。

  如需建立程序來警告您有關交易 ID 迴繞的相關資訊，請參閱 AWS 資料庫部落格文章中的針對 Amazon RDS for PostgreSQL 中的交易 ID 迴繞實作預警系統。

• 對於比較忙碌的資料表，除了依賴自動資料清理以外，請在維護時段定期執行手動清理凍結。如需執行手動清理凍結的資訊，請參閱 執行手動清理凍結。

判斷哪些資料表目前適合進行自動資料清理

通常有一或兩個資料表需要清理。表單中 relfrozenxid 的值大於 autovacuum_freeze_max_age 中交易的值，總是會成為自動資料清理的目標。否則，如果元組數因為最後一個 VACUUM 超出清理閾值而過時，則會清理資料表。

自動資料清理閾值已定義如下：

Vacuum-threshold = vacuum-base-threshold + vacuum-scale-factor * number-of-tuples

在哪vacuum base threshold裡autovacuum_vacuum_threshold，vacuum scale factor是autovacuum_vacuum_scale_factor，並且number of tuples是pg_class.reltuples。

當您連線到資料庫時，執行以下查詢可查看自動資料清理功能認為符合清理條件的資料表清單。

WITH vbt AS (SELECT setting AS autovacuum_vacuum_threshold FROM 
pg_settings WHERE name = 'autovacuum_vacuum_threshold'),
vsf AS (SELECT setting AS autovacuum_vacuum_scale_factor FROM 
pg_settings WHERE name = 'autovacuum_vacuum_scale_factor'), 
fma AS (SELECT setting AS autovacuum_freeze_max_age FROM pg_settings WHERE name = 'autovacuum_freeze_max_age'),
sto AS (select opt_oid, split_part(setting, '=', 1) as param,
split_part(setting, '=', 2) as value from (select oid opt_oid, unnest(reloptions) setting from pg_class) opt)
SELECT '"'||ns.nspname||'"."'||c.relname||'"' as relation,
pg_size_pretty(pg_table_size(c.oid)) as table_size,
age(relfrozenxid) as xid_age,
coalesce(cfma.value::float, autovacuum_freeze_max_age::float) autovacuum_freeze_max_age,
(coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) +
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * c.reltuples)
AS autovacuum_vacuum_tuples, n_dead_tup as dead_tuples FROM
pg_class c join pg_namespace ns on ns.oid = c.relnamespace 
join pg_stat_all_tables stat on stat.relid = c.oid join vbt on (1=1) join vsf on (1=1) join fma on (1=1)
left join sto cvbt on cvbt.param = 'autovacuum_vacuum_threshold' and c.oid = cvbt.opt_oid 
left join sto cvsf on cvsf.param = 'autovacuum_vacuum_scale_factor' and c.oid = cvsf.opt_oid
left join sto cfma on cfma.param = 'autovacuum_freeze_max_age' and c.oid = cfma.opt_oid
WHERE c.relkind = 'r' and nspname <> 'pg_catalog'
AND (age(relfrozenxid) >= coalesce(cfma.value::float, autovacuum_freeze_max_age::float)
OR coalesce(cvbt.value::float, autovacuum_vacuum_threshold::float) + 
coalesce(cvsf.value::float,autovacuum_vacuum_scale_factor::float) * 
c.reltuples <= n_dead_tup)
ORDER BY age(relfrozenxid) DESC LIMIT 50;

判斷自動資料清理目前是否執行中且執行多久時間

如果您需要手動清理資料表，請判斷目前是否在執行自動資料清理功能。若是，您可能需要調整參數，使其更有效率地執行，或暫時關閉自動資料清理功能，以便您手動執行 VACUUM。

使用以下查詢來判斷自動資料清理是否執行中、已執行多久時間，以及是否正等待另一個工作階段。

SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query
FROM pg_stat_activity 
WHERE upper(query) LIKE '%VACUUM%' 
ORDER BY xact_start;

在執行此查詢之後，您應會看到類似底下的輸出：

 datname | usename  |  pid  | state  | wait_event |      xact_runtime       | query  
 --------+----------+-------+--------+------------+-------------------------+--------------------------------------------------------------------------------------------------------
 mydb    | rdsadmin | 16473 | active |            | 33 days 16:32:11.600656 | autovacuum: VACUUM ANALYZE public.mytable1 (to prevent wraparound)
 mydb    | rdsadmin | 22553 | active |            | 14 days 09:15:34.073141 | autovacuum: VACUUM ANALYZE public.mytable2 (to prevent wraparound)
 mydb    | rdsadmin | 41909 | active |            | 3 days 02:43:54.203349  | autovacuum: VACUUM ANALYZE public.mytable3
 mydb    | rdsadmin |   618 | active |            | 00:00:00                | SELECT datname, usename, pid, state, wait_event, current_timestamp - xact_start AS xact_runtime, query+
         |          |       |        |            |                         | FROM pg_stat_activity                                                                                 +
         |          |       |        |            |                         | WHERE query like '%VACUUM%'                                                                           +
         |          |       |        |            |                         | ORDER BY xact_start;                                                                                  +

有幾個問題可能造成長時間執行自動資料清理階段 (長達數天)。最常見的問題就是資料表大小或更新率的 maintenance_work_mem 參數值設得太低。

建議您依照下列公式來設定 maintenance_work_mem 參數值。

GREATEST({DBInstanceClassMemory/63963136*1024},65536)

短時間執行的自動資料清理工作階段也可以指出問題：

• 它可指出您的工作負載沒有足夠的 autovacuum_max_workers。在此情況下，您需要指出工作者數目。

• 它可指出有索引損毀 (自動資料清理會當機並以相同的關聯重新啟動，但沒有任何進度)。在這種情況下，請手動執行 vacuum freeze verbose table 來查看確切原因。

執行手動清理凍結

您可以在清理程序已在執行中的資料表上執行手動清理。如果您已辨識出表單的交易將近 20 億 (或超出您所監控的任何閾值) 的資料表，此功能將很實用。

下列步驟是準則，而程序會有多種變化。例如，在測試期間，假設您會發現 maintenance_work_mem 參數值設定的太小而您需要對資料表採取立即行動。不過，或許您當下不想退回執行個體。使用上個區段所列的查詢，您可判斷哪個資料表有問題，並注意長時間執行的自動資料清理工作階段。您知道您必須變更 maintenance_work_mem 參數設定，但您也需要採取立即動作並清理有問題的資料表。以下程序說明在此情況下的處理方式。

手動執行清理凍結

1. 對包含要清理之資料表的資料庫，開啟兩個工作階段。在第二個工作階段中，如果連線中斷，請使用 "screen" 或其他公用程式來維持此工作階段。

2. 在第一個工作階段中，取得在資料表上執行之自動資料清理工作階段的處理程序 ID (PID)。

   執行以下查詢來取得自動資料清理工作階段的 PID。

   SELECT datname, usename, pid, current_timestamp - xact_start 
   AS xact_runtime, query
   FROM pg_stat_activity WHERE upper(query) LIKE '%VACUUM%' ORDER BY 
   xact_start; 

3. 在第二個工作階段中，計算您需要用於此作業的記憶體數量。在此範例中，我們判斷我們可以將最多 2 GB 的記憶體使用於此作業，所以將目前工作階段的 maintenance_work_mem 設定為 2 GB。

   SET maintenance_work_mem='2 GB';
   SET

4. 在第二個工作階段中，對表格發佈 vacuum freeze verbose 指令。詳細資訊設定很實用，因為即使 PostgreSQL 中目前沒有此工作階段的進度報告，您仍可查看活動。

   \timing on
   Timing is on.
   vacuum freeze verbose pgbench_branches;

   INFO:  vacuuming "public.pgbench_branches"
   INFO:  index "pgbench_branches_pkey" now contains 50 row versions in 2 pages
   DETAIL:  0 index row versions were removed.
   0 index pages have been deleted, 0 are currently reusable.
   CPU 0.00s/0.00u sec elapsed 0.00 sec.
   INFO:  index "pgbench_branches_test_index" now contains 50 row versions in 2 pages
   DETAIL:  0 index row versions were removed.
   0 index pages have been deleted, 0 are currently reusable.
   CPU 0.00s/0.00u sec elapsed 0.00 sec.
   INFO:  "pgbench_branches": found 0 removable, 50 nonremovable row versions 
        in 43 out of 43 pages
   DETAIL:  0 dead row versions cannot be removed yet.
   There were 9347 unused item pointers.
   0 pages are entirely empty.
   CPU 0.00s/0.00u sec elapsed 0.00 sec.
   VACUUM
   Time: 2.765 ms
   

5. 在第一個工作階段，如果自動資料清理封鎖清理工作階段，您會在 pg_stat_activity 中看見清理工作階段的等待為 "T"。在此情況下，您需要按如下方式結束自動資料清理程序。

   SELECT pg_terminate_backend('the_pid'); 

   此時，您的工作階段會開始。請特別注意，自動資料清理會立即重新啟動，因為此資料表可能排在其工作清單的最前面。

6. 在第二個工作階段中啟動您的 vacuum freeze verbose 命令，然後在第一個工作階段中結束自動資料清理程序。

在自動資料清理執行時重新為資料表建立索引

如果索引毀損，自動資料清理會繼續處理資料表並且失敗。如果您在此情況下嘗試手動清理，則會收到如下錯誤訊息。

postgres=>  vacuum freeze pgbench_branches;
ERROR: index "pgbench_branches_test_index" contains unexpected 
   zero page at block 30521
HINT: Please REINDEX it. 

當索引毀損且自動資料清理嘗試在資料表上執行時，您全力應付已在執行中的自動資料清理工作階段。當您發佈 REINDEX 指令，您開啟表單上的獨佔鎖定。寫入操作遭到封鎖，也使用特定索引讀取操作。

在資料表上執行自動資料清理時重新為資料表建立索引

1. 對包含要清理之資料表的資料庫，開啟兩個工作階段。在第二個工作階段中，如果連線中斷，請使用 "screen" 或其他公用程式來維持此工作階段。

2. 在第一個工作階段中，取得在資料表上執行之自動資料清理工作階段的 PID。

   執行以下查詢來取得自動資料清理工作階段的 PID。

   SELECT datname, usename, pid, current_timestamp - xact_start 
   AS xact_runtime, query
   FROM pg_stat_activity WHERE upper(query) like '%VACUUM%' ORDER BY 
   xact_start; 

3. 在第二個工作階段中，發出 reindex 命令。

   \timing on
   Timing is on.
   reindex index pgbench_branches_test_index;
   REINDEX
     Time: 9.966 ms
   

4. 在第一個工作階段中，如果自動資料清理封鎖處理程序，您會在 pg_stat_activity 中看見清理工作階段的等待為 "T"。在此情況下，您就結束自動資料清理程序。

   SELECT pg_terminate_backend('the_pid');

   此時，您的工作階段會開始。請特別注意，自動資料清理會立即重新啟動，因為此資料表可能排在其工作清單的最前面。

5. 在第二個工作階段中啟動您的命令，然後在第一個工作階段中結束自動資料清理程序。

使用大型索引管理自動清空

作為其操作的一部分，自動清空會在資料表上執行時執行數個清空階段。在清除資料表之前，首先會清空其所有索引。移除多個大型索引時，此階段會耗用大量的時間和資源。因此，最佳實務是務必控制資料表上的索引數目，並清除未使用的索引。

在此程序中，首先檢查整體索引大小。然後，判斷是否有可以移除的潛在未用索引，如下列範例所示。

檢查資料表及其索引的大小

postgres=> select pg_size_pretty(pg_relation_size('pgbench_accounts'));
pg_size_pretty
6404 MB
(1 row)

postgres=> select pg_size_pretty(pg_indexes_size('pgbench_accounts'));
pg_size_pretty
11 GB
(1 row)

在此範例中，索引的大小大於資料表。這種差異可能會導致性能問題，因為索引膨脹或未使用，這會影響自動清空以及插入操作。

檢查是否有未使用的索引

使用 pg_stat_user_indexes 檢視，您可以檢查索引與 idx_scan 資料欄搭配使用的頻率。在下列範例中，未使用的索引的 idx_scan 值為 0。

postgres=> select * from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
    
relid  | indexrelid | schemaname | relname          | indexrelname          | idx_scan | idx_tup_read | idx_tup_fetch
-------+------------+------------+------------------+-----------------------+----------+--------------+---------------
16433  | 16454      | public     | pgbench_accounts | index_f               | 6        | 6            | 0
16433  | 16450      | public     | pgbench_accounts | index_b               | 3        | 199999       | 0
16433  | 16447      | public     | pgbench_accounts | pgbench_accounts_pkey | 0        | 0            | 0
16433  | 16452      | public     | pgbench_accounts | index_d               | 0        | 0            | 0
16433  | 16453      | public     | pgbench_accounts | index_e               | 0        | 0            | 0
16433  | 16451      | public     | pgbench_accounts | index_c               | 0        | 0            | 0
16433  | 16449      | public     | pgbench_accounts | index_a               | 0        | 0            | 0
(7 rows)        
    

postgres=> select schemaname, relname, indexrelname, idx_scan from pg_stat_user_indexes where relname = 'pgbench_accounts' order by idx_scan desc;
    
schemaname  | relname          | indexrelname          | idx_scan
------------+------------------+-----------------------+----------
public      | pgbench_accounts | index_f               | 6
public      | pgbench_accounts | index_b               | 3
public      | pgbench_accounts | pgbench_accounts_pkey | 0
public      | pgbench_accounts | index_d               | 0
public      | pgbench_accounts | index_e               | 0
public      | pgbench_accounts | index_c               | 0
public      | pgbench_accounts | index_a               | 0
(7 rows)        
    

注意

這些統計資訊是從統計資訊重設時開始累計的。假設您有僅在營業季度結束時使用的索引，或僅用於特定報告的索引。自統計資訊重設以來，可能尚未使用此索引。如需詳細資訊，請參閱統計資訊函數。用來強制執行唯一性的索引不會執行掃描，也不應將其識別為未使用的索引。若要識別未使用的索引，您應該對應用程式及其查詢有深入的理解。

若要檢查上次何時重設資料庫的統計資訊，請使用 pg_stat_database

postgres=> select datname, stats_reset from pg_stat_database where datname = 'postgres';
    
datname   | stats_reset
----------+-------------------------------
postgres  | 2022-11-17 08:58:11.427224+00
(1 row)       
    

盡快清空資料表

RDS for PostgreSQL 12 和更新版本

如果大型資料表中有太多索引，您的資料庫執行個體可能接近交易 ID 包圍 (XID)，也就是當 XID 計數器包圍至零時。若保持取消核取的狀態，此情況可能會導致資料遺失。不過，您可以在不清除索引的情況下快速清空資料表。在 RDS for PostgreSQL 12 及更新版本中，您可以使用 VACUUM 搭配 INDEX_CLEANUP 子句。

postgres=> VACUUM (INDEX_CLEANUP FALSE, VERBOSE TRUE) pgbench_accounts;
        
INFO: vacuuming "public.pgbench_accounts"
INFO: table "pgbench_accounts": found 0 removable, 8 nonremovable row versions in 1 out of 819673 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 7517
Skipped 0 pages due to buffer pins, 0 frozen pages.
CPU: user: 0.01 s, system: 0.00 s, elapsed: 0.01 s.
        

如果自動清空工作階段已在執行中，您必須終止它才能開始手動 VACUUM。如需執行手動清空凍結的相關資訊，請參閱 執行手動清理凍結。

注意

定期略過索引清除可能會導致索引膨脹，這會影響整體掃描效能。作為最佳實務，只使用上述程序來防止交易 ID 包圍。

RDS for PostgreSQL 11 和更舊版本

不過，在 RDS for PostgreSQL 11 和更舊版本中，允許清空更快完成的唯一方法是減少資料表上的索引數目。捨棄索引可能會影響查詢計畫。我們建議您先捨棄未使用的索引，然後在 XID 包圍非常接近時捨棄索引。在清空程序完成之後，您可以重新建立這些索引。

影響自動資料清理的其他參數

以下查詢顯示會直接影響自動資料清理及其行為的某些參數值。PostgreSQL 文件會完整說明自動資料清理參數。

SELECT name, setting, unit, short_desc
FROM pg_settings
WHERE name IN (
'autovacuum_max_workers',
'autovacuum_analyze_scale_factor',
'autovacuum_naptime',
'autovacuum_analyze_threshold',
'autovacuum_analyze_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_scale_factor',
'autovacuum_vacuum_threshold',
'autovacuum_vacuum_cost_delay',
'autovacuum_vacuum_cost_limit',
'vacuum_cost_limit',
'autovacuum_freeze_max_age',
'maintenance_work_mem',
'vacuum_freeze_min_age');

雖然這些全都會影響自動資料清理，其中最重要的參數如下：

• maintenance_work_mem

• autovacuum_freeze_max_age

• autovacuum_max_workers

• autovacuum_vacuum_cost_delay

• autovacuum_vacuum_cost_limit

設定自動資料清理參數資料表層級

您可以在資料表層級設定自動資料清理相關的儲存參數，這比改變整個資料庫的行為更理想。對於大型資料表，您可能需要設定積極的設定值，而且不想讓自動資料清理以那種方式對待所有的資料表。

以下查詢顯示哪些資料表目前已備妥資料表層級選項。

SELECT relname, reloptions
FROM pg_class
WHERE reloptions IS NOT null;

在比您其餘的資料表大許多的資料表範例上，此查詢可能很實用。假設您有一個 300 GB 的表單，及 30 個少於 1 GB 的其他表單。在此情況下，您可以為大型資料表設定一些特定參數，您就不會改變整個系統的行為。

ALTER TABLE mytable set (autovacuum_vacuum_cost_delay=0);

這麼做會針對此資料表關閉成本型自動資料清理延遲，代價是在您系統上使用更多資源。通常情況下，每次達到 autovacuum_cost_limit 時，自動資料清理都會暫停 autovacuum_vacuum_cost_delay。如需詳細資訊，請參閱 PostgreSQL 文件中的成本型清理。

記錄清理和自動資料清理活動

有關自動資料清理活動的資訊將根據 rds.force_autovacuum_logging_level 參數中指定的層級傳送到 postgresql.log。以下是此參數允許的值，以及預設為該值的 PostgreSQL 版本：

• disabled (PostgreSQL 10、PostgreSQL 9.6)

• debug5, debug4, debug3, debug2, debug1

• info (PostgreSQL 12、PostgreSQL 11)

• notice

• warning (PostgreSQL 13 及以上)

• error、日誌、fatal、panic

rds.force_autovacuum_logging_level 使用 log_autovacuum_min_duration 參數。log_autovacuum_min_duration 參數的值是記錄自動資料清理動作的閾值 (以毫秒為單位)。設定為 -1，表示不會記錄任何內容；設定為 0，則會記錄所有動作。如同 rds.force_autovacuum_logging_level，log_autovacuum_min_duration 的預設值取決於版本，如下所示：

• 10000 ms：PostgreSQL 14、PostgreSQL 13、PostgreSQL 12 和 PostgreSQL 11

• (empty)：PostgreSQL 10 和 PostgreSQL 9.6 沒有預設值

建議您將 rds.force_autovacuum_logging_level 設定為 WARNING。我們也建議您將 log_autovacuum_min_duration 設定為 1000 到 5000 之間的值。設定為 5000，表示會記錄時間超過 5,000 毫秒的活動。如果鎖定衝突或同時刪除關係導致跳過自動資料清理動作，-1 以外的任何設定也會記錄訊息。如需詳細資訊，請參閱 PostgreSQL 文件中的自動資料清理。

若要解決問題，您可以將 rds.force_autovacuum_logging_level 參數變更為其中一個除錯等級 (從 debug1 至 debug5)，以取得詳盡資訊。我們建議您在短時間內使用除錯設定，並且僅用於疑難排解目的。如需進一步了解，請參閱 PostgreSQL 文件中的何時記錄。

注意

PostgreSQL 可讓 rds_superuser 帳戶檢視 pg_stat_activity 中的自動資料清理工作階段。例如，您可以找出並終止會阻擋命令執行的自動資料清理工作階段，或是執行速度比手動發出的清理命令還要慢的自動資料清理工作階段。