GaussDB for DWS表膨脹原理(上)

DWS表膨脹原理(上)

1 背景

對(duì)GaussDB for DWS數(shù)據(jù)庫(kù)有一定了解的朋友都知道GaussDB for DWS的UPDATE, DELETE操作是通過(guò)新增tuple版本提供高并發(fā)處理的. 這樣帶來(lái)一個(gè)問(wèn)題是需要經(jīng)常vacuum 表, 回收老版本占用的存儲(chǔ)空間. 只有回收的空間才能被重復(fù)利用, 如果回收不及時(shí)將會(huì)造成表的膨脹效應(yīng)。

2 表膨脹的原因

經(jīng)常看到有人說(shuō)表又膨脹了，那么導(dǎo)致對(duì)象膨脹的常見(jiàn)原因有哪些呢？

2.1未開(kāi)啟autovacuum

對(duì)于未開(kāi)啟autovacuum的用戶，同時(shí)又沒(méi)有合理的自定義vacuum調(diào)度的話，表的垃圾沒(méi)有及時(shí)回收，新的數(shù)據(jù)又不斷進(jìn)來(lái)，膨脹是必然的。（新的數(shù)據(jù)包括插入和更新，更新產(chǎn)生新版本的記錄）

2.2 資源回收不及時(shí)

開(kāi)啟了autovacuum, 但是各種原因?qū)е禄厥詹患皶r(shí)，并且新的數(shù)據(jù)又不斷產(chǎn)生，從而導(dǎo)致膨脹。回收不及時(shí)的原因：

當(dāng)數(shù)據(jù)庫(kù)非常繁忙時(shí)，如果IO比較差，會(huì)導(dǎo)致回收垃圾變慢，從而導(dǎo)致膨脹。

這種一般出現(xiàn)在數(shù)據(jù)庫(kù)中存在非常巨大的表，并且這些表在執(zhí)行whole table vacuum (prevent xid wrapped, 或當(dāng)表的年齡大于vacuum_freeze_table_age時(shí)會(huì)全表掃)，因此產(chǎn)生大量IO，這期間很容易導(dǎo)致自身或其他表膨脹。

什么情況會(huì)觸發(fā)autovacuum呢?

* A table needs to be vacuumed if the number of dead tuples exceeds a

* threshold.? This threshold is calculated as

* threshold = vac_base_thresh + vac_scale_factor * reltuples

如果沒(méi)有設(shè)置表級(jí)別的autovacuum thresh和factor,那么默認(rèn)使用參數(shù)文件配置的值。如下：

int???????????????????? autovacuum_vac_thresh;? // 默認(rèn)50

double????? ????autovacuum_vac_scale;? // 默認(rèn)0.2

也就是說(shuō)dead tuple達(dá)到約為表的20%時(shí)，才觸發(fā)autovacuum。然后回收又需要一定的時(shí)間，所以最終表的膨脹應(yīng)該是超過(guò)20%的。

所有worker繁忙，某些表產(chǎn)生的垃圾如果超過(guò)閾值，但是在此期間沒(méi)有worker可以為它處理垃圾回收的事情。導(dǎo)致可能發(fā)生膨脹。

如果數(shù)據(jù)庫(kù)的表很多，而且都比較大，那么當(dāng)需要vacuum的表超過(guò)了配置autovacuum_max_workers的數(shù)量，某些表就要等待空閑的worker。這個(gè)階段就容易出現(xiàn)表的膨脹。

通過(guò)pg_stat_activity.backend_xid和backend_xmin來(lái)觀察。

backend_xid表示已申請(qǐng)事務(wù)號(hào)的事務(wù)，例如有增刪改，DLL等操作的事務(wù)。backend_xid從申請(qǐng)事務(wù)號(hào)開(kāi)始持續(xù)到事務(wù)結(jié)束。

backend_xmin表示SQL執(zhí)行時(shí)的snapshot，即可見(jiàn)的最大已提交事務(wù)。例如查詢語(yǔ)句，查詢游標(biāo)。backend_xmin從SQL開(kāi)始持續(xù)到SQL結(jié)束，如果是游標(biāo)的話，持續(xù)到游標(biāo)關(guān)閉。

當(dāng)DWS數(shù)據(jù)庫(kù)中存在未結(jié)束的SQL語(yǔ)句或者未結(jié)束的持有事務(wù)ID的事務(wù)，在此事務(wù)過(guò)程中，或在此SQL執(zhí)行時(shí)間范圍內(nèi)產(chǎn)生垃圾的話，這些垃圾無(wú)法回收，導(dǎo)致數(shù)據(jù)庫(kù)膨脹。

也即是判斷當(dāng)前數(shù)據(jù)庫(kù)中backend_xid和backend_xmin最小的值，凡是超過(guò)這個(gè)最小值的事務(wù)產(chǎn)生的垃圾都不能回收。

在開(kāi)啟了autovacuum_vacuum_cost_delay后，會(huì)使用基于成本的垃圾回收，這個(gè)可以有利于降低VACUUM帶來(lái)的IO影響，但是對(duì)于IO沒(méi)有問(wèn)題的系統(tǒng)，就沒(méi)有必要開(kāi)啟autovacuum_vacuum_cost_delay，因?yàn)檫@會(huì)使得垃圾回收的時(shí)間變長(zhǎng)。

喚醒時(shí)間由參數(shù)autovacuum_naptime決定，autovacuum launcher進(jìn)程負(fù)責(zé)告訴postmaster需要fork worker進(jìn)程來(lái)進(jìn)行垃圾回收，但是如果autovacuum launcher進(jìn)程一直在睡覺(jué)的話，那完蛋了，有垃圾了它還在睡覺(jué)，那不就等著膨脹嗎？

例如對(duì)于一個(gè)10GB的表，一條SQL或一個(gè)事務(wù)中刪除或更新9GB的數(shù)據(jù)，這9GB的數(shù)據(jù)必須在事務(wù)結(jié)束后才能進(jìn)行垃圾回收，無(wú)形中增加了膨脹的可能。

大量的非HOT更新，會(huì)導(dǎo)致索引膨脹，對(duì)于BTREE索引來(lái)說(shuō)，整個(gè)索引頁(yè)沒(méi)有任何引用才能被回收利用，因此索引比較容易膨脹。

專(zhuān)業(yè)名詞

Relpages：以頁(yè)(大小為BLCKSZ)為單位的此表在磁盤(pán)上的大小，它只是優(yōu)化器用的一個(gè)近似值；

PageData：每個(gè) page 頭包含24字節(jié)固定長(zhǎng)度；

PageNum：page的數(shù)量；

n_live_tup：估計(jì)活躍行數(shù)；

live tuple：活躍行數(shù)；

SQL 數(shù)據(jù)倉(cāng)庫(kù)服務(wù) GaussDB(DWS)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。