GaussDB(DWS)磁盤使用率相關問題定位指南

磁盤使用率相關問題定位指南

一、定位思路

1.1 核心思想

確定是哪個目錄占用空間異常，再具體處理

1.2定位三板斧

1.?????? 通過橫向與縱向對比，確定占用空間異常的實例與最小級別目錄。（橫向對比：單實例或部分實例磁盤使用率異常時，對比不同實例上各目錄大小差異；縱向對比：所有實例磁盤使用率異常增高時，與之前的磁盤使用情況進行對比）

2.?????? 確認目錄后按照對應場景處理

3.?????? 磁盤使用率達到90%后，處理時需注意集群的只讀狀態；磁盤使用率達到100%后，直接聯系華為工程師

二、定位分析

2.1常用命令

查看磁盤使用率

df -h

查看某個目錄占用空間大小

du -sh 目錄

查看當前目錄下各文件/目錄占用空間大小

du -sh *

查看集群狀態（包含實例目錄）

cm_ctl query -Cvd

查看對應dn的端口號

cat dn目錄/postgresql.conf |grep port

例：cat /srv/BigData/mppdb/data1/master1/postgresql.conf | grep port

2.2場景劃分

目錄結構概覽（此處只列舉常見目錄，下層目錄只以master為例展開）

2.2.1 archive目錄占用空間較大

現象

單個或多個實例archive目錄占用空間較大

根因

打開了日志歸檔參數archive_mode，導致archive目錄下不斷歸檔xlog，占用空間越來越大

應急

1）? 關閉歸檔參數

gs_guc reload -Z coordinator -Z datanode -N all -I all -c "archive_mode=off"

2）? 手動清理archive目錄下的歸檔日志（歸檔日志并不影響集群運行，一般不建議打開。現網問題刪除操作需與客戶確認）

archive目錄下文件數量過多時，可能無法使用rm -f *命令進行刪除，可參看以下命令分批刪除

find -name "*" | xargs -n 10 rm -f

2.2.2 pg_xlog目錄占用空間較大且未打開歸檔

現象

pg_xlog占用空間大，pg_xlog目錄下文件數量多，archive目錄占用空間不大

分析

1）? 遇到此場景時，優先查看集群狀態，確認此dn的對端（例：dn6001的對端是dn6002）是否狀態異常，若當前dn為從備，則查看同一dn環的主備是否有一個發生故障。當主備有一個dn狀態異常時，另一副本數據和xlog會存放在從備，在備機恢復之前不會回收。若遇到此場景，則應優先考慮如何將集群恢復為normal。

2）? 若集群狀態正常，主dn的xlog過多，可能是因為主備xlog同步較慢導致，可在備機所在節點執行”gs_ctl querybuild -D 備機目錄”查看同步進度

3）? 若主備日志同步進度為100%，大量xlog為最近突然產生，則排查業務上是否有帶索引導入的場景。導入的目標表如果有索引，有可能產生大量xlog

根因

1）? 主備dn有一個發生故障導致xlog在當前主機和從備積壓

2）? 主備日志同步較慢導致主dn日志堆積

3）? 帶索引導入產生大量xlog

應急

1）? 若滿足根因1，則優先恢復集群狀態，恢復normal后會自動進行xlog同步，同步結束后自動回收

2）? 若滿足根因2，則查看IO狀況，結合日志分析

3）? 若滿足根因3，則排查業務側是否有對應情況，中斷該業務，刪除目標表的索引，再導入，導入結束后再重新創建索引

4）? 若無法快速恢復集群狀態，或無法快速定位，此場景可直接聯系華為工程師處理

2.2.3 pgsql_tmp目錄占用空間大

現象

單個或多個實例的pgsql_tmp目錄占用空間大

分析

psql_tmp目錄存放的是臨時下盤文件，這個目錄大說明產生了大量的算子下盤，需找到具體語句，殺掉該語句后空間自動恢復

pgsql_tmp目錄下臨時文件的命名方式類似pgsql_tmp140359455721216.9，其中紅色部分表示產生該臨時文件的線程號，最后的9表示這個文件是該線程產生的第九個文件

根因

臨時文件下盤

應急

1）? 通過查看pgsql_tmp目錄下的文件名，確定產生下盤文件的線程號

2）? 根據該線程號，連到對應實例（-d 使用postgres即可，因為pg_stat_activity可以查到所有庫的；-p 使用該實例的端口號，查看端口號的方法參考2.1常用命令），執行

”select * from pg_stat_activity where pid = pid”

即可查到產生下盤文件的語句

3）? 在該實例執行

”select * from pg_terminate_backend(pid)”

即可殺掉該語句

4）? 對該業務語句進行調優，優化后再上線

5）? 若情況比較緊急，可直接kill dn進行應急，但是如果不定位到具體語句，業務再次拉起后仍會復現

2.2.4 base目錄下的database目錄占用空間異常增高

現象

單個或多個實例base目錄下的庫目錄（除pgsql_tmp以外的目錄）占用空間高

分析

遇到此場景時，應優先確定是部分dn的database目錄占用空間大，還是所有dn的database目錄占用空間都高。如果是部分dn，則通過對比正常dn和異常dn目錄下的文件找到占空間大的對象；如果是所有dn的database目錄都異常增高，則選擇一個dn實例排查大表或最近更新的文件。

database目錄下，文件的命名方式，行存表或行存表分區為12345.1，其中紅色部分為relfilenode，最后的數字表示這是該relation的第幾個文件；列存表為12345_C10.1，其中紅色部分表示relfilenode，C10表示這是第幾列，最后的數字表示這是該relation第10列的第幾個文件；每個文件大小達到1G后開啟下一個文件

詳細步驟如下

1.?????? 部分dn的庫目錄占用空間大

1）? database的oid在不同dn上有可能不同

分別連接（-d postgres -p 對應dn端口）異常dn和正常dn，執行”select oid,* from pg_database” 并結合base目錄下各database目錄的大小，進行比對，確定占用空間高的database

2）? 在正常dn和異常dn分別進入該目錄，執行ll *.100

對比兩邊大于100G的relation數量，例如正常dn是3個，異常dn是5個，有明顯差異，則對異常dn上5個大于100G的relation均進行排查（因為同一個relation的relfilenode在不同dn可能不同，因此不能直接確定排除哪3個）；如果在正常dn和異常dn上的結果一致，則縮小范圍，例如ll *.50，ll *.10，ll *.5甚至ll *.1進行對比，找到差別后依次排查，數量較多時可在文本編輯器中使用列編輯功能批量編輯sql語句。

連接到異常dn對應的database，執行

”select * from pg_class where relfilenode = relfilenode”

如果可以查到結果，則relname就是對應的relation，可能為表或者索引；

如果在pg_class中查不到對應的relation，則執行

”select * from pg_class where oid = (select parentid from pg_partition where relfilenode = relfilenode)”

如果可以查到結果，則說明該relation是分區表的一個分區，我們通過上面的語句查到了對應的主表；

當查到對應的表或索引后，可以通過執行

“select * from pg_namespace where oid = relnamespace”

獲得該對象的schema，其中relnamespace可以在pg_class的結果中獲得；如果操作人員知道對應表的schema，則可以跳過此步驟

如果在pg_class和pg_partition中都查不到記錄，則需進一步確認該relation是否為系統表，此時建議聯系華為工程師處理。

3）? 通過上一步，我們找到了懷疑對象，接下來要進行確認

對每一個懷疑對象（表或索引），連接到正常dn和異常dn的對應database庫，分別執行

”\dt+ schema.relation”

對比該對象在兩個dn上占用空間大小，若大小確實相差較大，則說明該對象是我們要找的目標

4）? 確定所有目標對象后，依次進行處理

若對象為索引，則排查索引對應的表是否也存在傾斜；連接到正常dn和異常dn的對應database，執行

“select count(*) from schema.relation”

若表有明顯傾斜，則對表進行整改；若表沒有傾斜，則執行reindex重建索引

“reindex table schema.relation”

若對象為表，則直接在正常dn和異常dn的對應database，執行

“select count(*) from schema.relation”

若表有明顯傾斜，則對表進行整改；若表沒有傾斜，則對該表做vacuum full

“vacuum full table”

5）? 若清理大表之后，空間仍未下降，則查看文件fd是否仍被占用

“lsof -n $data目錄 |grep deleted”

若出現此情況，空間最終會被釋放，但是可能比較慢，可以kill dn進程快速恢復

2.?????? 所有dn的database目錄都高，則選擇一個dn進行分析

1）??? 連接到對應dn，執行

“select oid,* from pg_database”

結合base目錄下各database目錄的大小，確定占用空間高的database

2）??? 進入該database目錄，執行ll *.100，找出占用空間大的relation，若結果為空，則依次執行ll *.50，ll *.30，ll *.10，ll *.5，ll *.1等，查找占用空間大的對象；若無明顯占用空間大的對象，或大小接近的對象數量非常多，則根據磁盤空間上漲的時間，查看最后更新時間與上漲時間接近的文件，確定relfilenode

3）??? 連接到該dn對應的database，執行

”select * from pg_class where relfilenode = relfilenode”

如果可以查到結果，則relname就是對應的relation，可能為表或者索引；

如果在pg_class中查不到對應的relation，則執行

”select * from pg_class where oid = (select parentid from pg_partition where relfilenode = relfilenode)”

如果可以查到結果，則說明該relation是分區表的一個分區，我們通過上面的語句查到了對應的主表；

當查到對應的表或索引后，可以通過執行

“select * from pg_namespace where oid = relnamespace”

獲得該對象的schema，其中relnamespace可以在pg_class的結果中獲得；如果操作人員知道對應表的schema，則可以跳過此步驟

如果在pg_class和pg_partition中都查不到記錄，則需進一步確認該relation是否為系統表，此時建議聯系華為工程師處理.

4）??? 對查出來的表，在該dn上執行

“\dt+ schema.relation”

查看目標對象在單dn的大小，對占用空間過大的表進行清理（需客戶同意）（如果是用delete的方式清理，則清理之后需再做vacuum full）

5）??? 若清理大表之后，空間仍未下降，則查看文件fd是否仍被占用

“lsof -n $data目錄 |grep deleted”

若出現此情況，空間最終會被釋放，但是可能比較慢，可以kill dn進程快速恢復

2.2.5 其他場景一：core文件生成過多導致磁盤空間占滿

現象

實例頻繁core導致core文件過多將磁盤占滿

分析

查看core文件的路徑

”cat /proc/sys/kernel/core_pattern”

core文件占用空間過大，則重新配置core名稱，使core文件每次進行覆蓋，每個實例最多保存一個core

應急

1）?? echo "core" >/proc/sys/kernel/core_pattern

2）?? kill om_monitor

3）?? kill cm_agent

保留一兩個core文件，刪除其他core文件，聯系華為工程師分析

2.2.6 其他場景二：單個日志文件過大導致/var/log目錄磁盤空間占滿

現象

單個日志文件過大（om_monitor日志或system_call日志）導致/var/log目錄占滿

應急

1）? 將大日志文件cp到其他目錄；如果文件過大或情況緊急，則跳過此步驟

2）? 清空該日志文件內容

echo ‘cleanup’ > 日志文件

3）? 聯系華為工程師進一步分析

2.2.7 其他場景三：xfs文件系統預分配導致磁盤使用率高

現象

base目錄下某個database目錄占用空間大，但是找不到大文件

分析

遇到此場景時，統計該database目錄下文件總大小，與”du -sh *”的結果相比較，如果相差較多，說明是因為新建了大量的列存寬表，產生大量文件，每個文件在xfs上都會預占16M空間，導致磁盤空間上漲

應急

1）??? 以root用戶登錄空間占用高的服務器，執行以下語句釋放預占空間

sync

/sbin/sysctl -w vm.drop_caches=3

2）??? 部署drop cache腳本

2.3 磁盤空間達到90%

單個或多個RAID組的磁盤使用率超過90%后，集群會變為只讀狀態，無法進行寫操作。根據第三章的方法進行定位，如果處理時涉及重分布、vacuum full、reindex等操作，需要先解除集群的只讀狀態。這些手段使用時都會使磁盤空間先升后降，因此必須確保剩余空間足夠進行這些操作。

解除集群只讀：

1.?????? 在所有cn節點配置白名單，防止取消只讀狀態后有業務接入將磁盤插入至100%

cp /srv/BigData/mppdb/data1/coordinator/pg_hba.conf /home/omm/pg_hba.conf_`date +'%Y-%m-%d_%H%M%S'`

sed -i 's/.*sha256.*$/#&/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf

2.?????? 連接數據庫cn，確保當前沒有正在執行的業務語句

3.?????? 在主備cm_server節點的/opt/huawei/Bigdata/mppdb/cm/cm_server/cm_server.conf中修改

enable_transaction_read_only=off（關閉集群只讀監控）

依次kill -9 cm_server備機和主機進程（kill前后分別觀察進程號，進程號變化表示成功）

4.?????? 在后臺取消只讀狀態

gs_guc reload -Z coordinator -N all -I all -c "default_transaction_read_only = false"

5.?????? 把所有cn都kill一遍，防止有遺漏的正在執行的語句

執行完相關操作，確認空間已恢復后，需恢復集群白名單配置和CM的只讀檢測

此處需注意，一定要恢復白名單和CM的只讀檢測，否則下次磁盤使用率超過90%時將無法將集群置為只讀狀態，帶來嚴重后果

1.?????? 在主備cm_server節點的/opt/huawei/Bigdata/mppdb/cm/cm_server/cm_server.conf中修改

enable_transaction_read_only=on

依次kill -9 cm_server備機和主機

2.?????? 在所有cn節點恢復集群白名單配置

sed -i '/^#.*sha256.*$/s/^#//' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf

2.4???????? 磁盤空間達到100%

啥也別想了，趕緊找研發！

EI企業智能 Gauss AP 數據倉庫服務 GaussDB(DWS)

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。