解決greenplum數(shù)據(jù)庫truncate table或drop table很慢的問題

osdba

問題描述：   

    在solaris10上使用greenplum3.3.6，當(dāng)數(shù)據(jù)文件很多的，truncate table和drop table很慢，常常這樣一個操作需要3分鐘到十幾分鐘。這個問題直到greenplum4.0都存在。

原因分析：

    對于PostgreSQL數(shù)據(jù)庫來說每個表都是由一個或幾個文件組成的，文件由一個數(shù)據(jù)組成，如名稱為：123468，文件大小不能超過一個設(shè)定值，目前是1G，如果表的內(nèi)容超過了1G,g內(nèi)容寫到下一個加了”.數(shù)字"的文件中，如123468.1，當(dāng)123468.1寫滿了，再放到123468.2文件中，依此類推。當(dāng)greenplum在truncate table或drop table時，會把表對應(yīng)的文件刪除，刪除的方式是，先刪除123468這個文件，然后遍歷這個目錄下的所有文件，看這個目錄下的每一個文件名前面是否是123468.n的格式（n為1,2,3...)，如果是，再把這個文件刪除。隨著greenplum數(shù)據(jù)庫的變大，數(shù)據(jù)目錄下有幾十萬個文件甚至 到達(dá)百萬個文件，于是遍歷目錄就會很慢，這就是導(dǎo)致的greenplum3.3.X truncate table和drop table很慢的原因。

解決方法：

    與greenplum公司聯(lián)系過，他們說升級到greenplum4.1，這個問題就解決了，但由于一般的greenplum數(shù)據(jù)庫都比較大，而最新版本greenplum4.1還有一些bug，升級風(fēng)險很大。所以這個問題，于是只有自己想辦法解決這個問題。

    由于是遍歷目錄慢，能否讓系統(tǒng)跳過這個步驟。方法是，我寫一個動態(tài)庫fixgptrunc.so，這個動態(tài)庫重載列目錄的函數(shù)readdir_r，然后設(shè)置環(huán)境變量LD_PRELOAD_64：

export LD_PRELOAD_64=/home/gpadmin/fixgptrunc/fixgptrunc.so

    這樣當(dāng)，postgres進(jìn)程起來時，當(dāng)調(diào)用遍歷目錄的函數(shù)readdir_r時，就會調(diào)用我寫的這個動態(tài)庫中的readdir_r函數(shù)，而當(dāng)我的函數(shù) readdir_r，看到postgres是遍歷數(shù)據(jù)目錄時，就跳過。這樣這個性能問題就解決了。

這里大家可能有幾個疑問：

    1. 如果跳過了，那么那些帶后綴的123468.1、123468.2文件系統(tǒng)就不會刪除了，這怎么辦？ 我的解決方法是，也重載unlink函數(shù)，我的unlink在當(dāng)刪除123468文件時，就自動去把123468.1和123468.2這樣的文件都刪除 掉。

    2. 如果postgres進(jìn)程不是在做truncate table和drop table時，去調(diào)用readdir_r函數(shù)時，直接跳過，這樣是否會使用這些正常的需要調(diào)readdir_r的操作也會出現(xiàn)找不到文件的錯誤? 這個問題的解決方法是我的unlink函數(shù)會檢查調(diào)用unlink函數(shù)的父函數(shù)是否是mdunlink函數(shù)，mdunlink函數(shù)是 PostgreSQL的一個刪除表文件的函數(shù)，一般只會在做drop table或truncate table時才會調(diào)用mdunlink函數(shù)，除此之外的正常調(diào)用，則不會調(diào)用這個mdunlink函數(shù)，這樣就不會有這個問題了。如果父函數(shù)是 mdunlink，才跳過，否則按正常流程走。



程序使用方法：

   使用gmake生成fixgptrunc.so文件，

   然后把這個文件拷貝到master和各個segment結(jié)點，我測試的時候，放在/home/gpadmin/fixgptrunc/這個目錄下：

然后在.bashrc文件中增加環(huán)境變量：

export LD_PRELOAD_64=/home/gpadmin/fixgptrunc/fixgptrunc.so

export FIX_GP_TRUNC_DEBUG=1

   設(shè)置了環(huán)境變量FIX_GP_TRUNC_DEBUG=1，則會在/tmp文件目錄下生成一個log文件：fixgptrunc.log，便于調(diào) 試。

然后重啟greenplum后，再做truncate table或drop table就應(yīng)該很快了。

源代碼見我的blog:
http://blog.osdba.net/?post=56

tanfeng3

強(qiáng)啊，頂！

renxiao2003

沒搞過這么高森的問題。

zhanghb77

數(shù)據(jù)庫很大，而且又是64位環(huán)境，1G明顯太小。最好改下RELSEG_SIZE，再重build

renxiao2003

回復(fù) 4# zhanghb77


    說得有道理啊。