資訊專欄INFORMATION COLUMN
1、創建擴展
create extension pgstattuple; |
2、表膨脹查詢
如下查詢出來表的怕膨脹系數為81%。
select *, 1.0 - tuple_len::numeric / table_len as bloat from pgstattuple(tab_brin1); |
占用2414個page。
select * from pg_relpages(tab_brin1); |
3、表膨脹處理
vacuum (verbose,full,analyze) tab_brin1; |
它將進行普通的垃圾收集，將垃圾空間標識為可用的狀態。它不會影響其它事務發出的表上的讀操作和寫操作，因為普通的垃圾收集不會在表上加一個互斥鎖。
VacuumFull
啟動完全垃圾收集，完全垃圾收集會在表上加一個互斥鎖，對表進行垃圾回收期間，其它的事務不能對表進行讀操作和寫操作。VACUUMFULL比VACUUM的執行時間要長一些，執行的操作也多一些，它在進行垃圾收集的過程中，可能會將一個記錄從一個數據塊轉移到另一個數據塊。
Vacuumanalyze
除了回收垃圾空間還收集優化器統計數據
Vacuumverbose
輸出垃圾收集的詳細數據。
select *, 1.0 - tuple_len::numeric / table_len as bloat from pgstattuple(tab_brin1); |
表占用473個page。
select * from pg_relpages(tab_brin1); |
VacuumFreeze
為了保證同一個數據庫中的最新和最舊的兩個事務之間的年齡不超過2^31，postgresql引入了凍結(freeze)功能。
涉及到的術語：
1、表年齡：當前事務號距上一次執行freeze操作的事務id的差值
2、元組年齡：當前元組的xmin距上一次執行freeze操作的事務id的差值
如果發生當新老事務id差超過21億的時候，事務號會發生回卷，此時數據庫會報出如下錯誤并且拒絕接受所有連接，必須進入單用戶模式執行vacuumfreeze操作。
事務凍結操作：
vacuum freeze tab_brin1; |
查看指定表的年齡
SELECT relname, age(relfrozenxid) as xid_age,pg_size_pretty(pg_table_size(oid)) as table_size FROM pg_class WHERE relname = tab_brin1; |
查詢所有數據庫的年齡：
select datname, age(datfrozenxid) from pg_database; |
通常報錯如下：
error：database is not accepting commands to avoid wraparound data loss indatabase “mydb”
hint：stop the postmaster and vacuum that database in single-user mode
參數設置：
在postgresql中，vacuum是一個比較耗費io的過程，而vacuumfreeze更是被稱為“凍結炸彈”，因為涉及到了大量的讀寫io，讀io(datafile)和寫io(datafile以及寫wal)。對于業務繁忙的庫，可能會出現如下情況：
可能有很多大表的年齡會先后到達2億，數據庫的autovacuum會開始對這些表依次進行vacuumfreeze，從而集中式的爆發大量的讀寫io，數據庫和操作系統響應遲緩，如果又碰上業務高峰，會出現很不好的影響。
所以設置好參數尤為重要：
設置vacuum_cost_delay為一個比較高的數值（例如50ms），這樣可以減少普通vacuum對正常數據查詢的影響。
autovacuum_freeze_max_age和vacuum_freeze_table_age的值也不適合設置過大，因為過大會造成pg_clog中的日志文件堆積，來不及清理。我們把autovacuum_freeze_max_age設置為最大值20億。
vacuum_freeze_table_age設置為0.95* autovacuum_freeze_max_age。
vacuum_freeze_min_age不宜設置過小，比如我們freeze某個元組后，這個元組馬上又被更新，那么之前的freeze操作其實是無用功，freeze真正應該針對的是那些長時間不被更新的元組。
生產環境中做好pg_database.frozenxid的監控，當快達到觸發值時，我們應該選擇一個業務低峰期窗口主動執行vacuumfreeze操作，而不是等待數據庫被動觸發。
分區，把大表分成小表。每個表的數據量取決于系統的io能力，前面說了vacuumfreeze是掃全表的，現代的硬件每個表建議不超過32gb，單表數據不要超過3000w。
對大表設置不同的vacuum年齡
用戶自己調度 freeze，如在業務低谷的時間窗口，對年齡較大，數據量較大的表進行vacuumfreeze。
年齡只能降到系統存在的最早的長事務即 min(pg_stat_activity.(backend_xid,backend_xmin))。因此也需要密切關注長事務。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129950.html
摘要：以上出自發行說明，這段指出版本支持自動查殺超過指定時間的空閑事務連接，下面演示下。修改以下參數備注參數單位為毫秒，這里設置超時空閑事務時間為秒。數據庫日志備注數據庫日志里清晰地記錄了進程的連接由于空閑事務超時被斷開連接。 熟悉 PostgreSQL 的朋友應該知道 idle in transaction 進程，引發 idle in transaction 的原因很多，例如應用代碼中忘記...
摘要：深入解析系列之并發控制與事務機制并發控制旨在針對數據庫中對事務并行的場景，保證中的一致性與隔離。啟動并執行第一個命令。事務管理器分配，并返回事務快照，因為正在進行中。意味著該行由另一個并發事務更新，并且其事務尚未終止。 showImg(https://segmentfault.com/img/remote/1460000018081793); 深入解析 PostgreSQL 系列整理...
摘要：深入解析系列之并發控制與事務機制并發控制旨在針對數據庫中對事務并行的場景，保證中的一致性與隔離。啟動并執行第一個命令。事務管理器分配，并返回事務快照，因為正在進行中。意味著該行由另一個并發事務更新，并且其事務尚未終止。 showImg(https://segmentfault.com/img/remote/1460000018081793); 深入解析 PostgreSQL 系列整理...
摘要：這可以通過負載平衡來實現數據分片當問題不是并發查詢的數量，而是數據庫的大小和單個查詢的速度時，可以實現不同的方法。 showImg(https://segmentfault.com/img/remote/1460000018875091); 來源 | 愿碼(ChainDesk.CN)內容編輯 愿碼Slogan | 連接每個程序員的故事 網站 | http://chaindesk.cn...
閱讀 1346·2023-01-11 13:20
閱讀 1684·2023-01-11 13:20
閱讀 1132·2023-01-11 13:20
閱讀 1858·2023-01-11 13:20
閱讀 4100·2023-01-11 13:20
閱讀 2704·2023-01-11 13:20
閱讀 1385·2023-01-11 13:20
閱讀 3597·2023-01-11 13:20
