PostgreSQL痛點(diǎn)的解決方案是什么

這篇文章將為大家詳細(xì)講解有關(guān)PostgreSQL痛點(diǎn)的解決方案是什么，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

內(nèi)核必須為廣泛的工作負(fù)載而工作；它并不總是執(zhí)行得象一些用戶社區(qū)所希望的那么好，這可以說(shuō)不足為奇。PostgreSQL關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)項(xiàng)目是一個(gè)有時(shí)感到有些冷落的社區(qū)。在響應(yīng) 2014年 “Linux 存儲(chǔ)，文件系統(tǒng)，和內(nèi)存管理”峰會(huì)組織者的邀請(qǐng)時(shí)，PostgreSQL 開發(fā)商 Robert Haas，Andres Freund 和 Josh Berkus 到場(chǎng)來(lái)討論了他們最痛苦的問(wèn)題和可能的解決方案。

PostgreSQL是一個(gè)很老的系統(tǒng)，可以追溯到1996；它被很多用戶在多種操作系統(tǒng)上運(yùn)行。因此，PostgreSQL開發(fā)商被他們可以添加的Linux指定代碼的數(shù)量所限制。它是基于合作進(jìn)程的，沒(méi)使用線程。系統(tǒng) V 共享內(nèi)存用于進(jìn)程間通信。重要的是，PostgreSQL維護(hù)它自己的內(nèi)部緩沖區(qū)，但也使用 I/O 緩沖來(lái)讀寫磁盤數(shù)據(jù)。這種緩沖的組合導(dǎo)致了 PostgreSQL 用戶所經(jīng)歷的一些問(wèn)題。

同步緩慢

第一個(gè)被描述的問(wèn)題是關(guān)于數(shù)據(jù)如何從緩沖區(qū)高速緩存保存到磁盤上。PostgreSQL 使用了一種形式的日志記錄，他們稱之為“預(yù)寫式日志”。變化之處首先寫入到日志中；一旦日志安全的保存在磁盤上，主要的數(shù)據(jù)庫(kù)塊就能被回寫。這個(gè)工作中很多都通過(guò)一個(gè)“檢查點(diǎn)”進(jìn)程來(lái)完成；它寫入日志條目，之后將一批數(shù)據(jù)寫回到磁盤上的各種文件中。這種帶有日志能力的寫操作相對(duì)而言小而連續(xù)；他們的工作效果不錯(cuò)，并且，據(jù) Andres 所說(shuō)，PostgreSQL 的開發(fā)者對(duì)系統(tǒng)這部分在 Linux 上的運(yùn)行情況足夠滿意。[Robert Haas]

數(shù)據(jù)的寫入則是另一回事。檢查點(diǎn)進(jìn)程調(diào)節(jié)這些寫操作，從而避免 I/O 系統(tǒng)壓倒其它一切。但是，當(dāng)它開始考慮調(diào)用 fsync() 來(lái)確保數(shù)據(jù)被安全的寫入，并且所有這些被調(diào)節(jié)后的寫操作被立即推送到請(qǐng)求隊(duì)列時(shí)，就導(dǎo)致了 I/O 風(fēng)暴。據(jù)他們說(shuō)，問(wèn)題不是因?yàn)?fsync() 太慢，而是它太快了。它導(dǎo)出如此多的數(shù)據(jù)到 I/O 系統(tǒng)，以至于其它任何事情，包括應(yīng)用程序的讀請(qǐng)求等，都被阻塞住。這為用戶帶來(lái)了痛苦，同樣也為 PostgreSQL 的開發(fā)者帶來(lái)了痛苦。

Ted Ts'o 提問(wèn)，將檢查點(diǎn)進(jìn)程限定到 I/O 可用帶寬的特定百分比，是否能有幫助。但 Robert 回應(yīng)說(shuō)，I/O 優(yōu)先級(jí)應(yīng)該更好一些；檢查點(diǎn)進(jìn)程，在其它進(jìn)程不需要帶寬時(shí)，應(yīng)該更夠 100% 的使用它。使用 I/O 友好的機(jī)制（它會(huì)在 CFQ 調(diào)度器中控制 I/O 優(yōu)先級(jí)）被提出，但這也有問(wèn)題：它對(duì) fsync() 調(diào)用發(fā)起的 I/O 操作不起作用。即使來(lái)自檢查點(diǎn)進(jìn)程的數(shù)據(jù)被寫入（并非總是如此），當(dāng) fsync() 開始真正進(jìn)行 I/O 操作時(shí)，優(yōu)先級(jí)沒(méi)有實(shí)施上。

Ric Wheeler 建議，PostgreSQL 開發(fā)者需要更好的控制他們寫入數(shù)據(jù)的速度；Chris Mason 補(bǔ)充說(shuō)，當(dāng)產(chǎn)生 I/O 請(qǐng)求時(shí)，O_DATASYNC 選項(xiàng)可以用來(lái)給以更好的控制。這里的問(wèn)題是，這種方式的實(shí)現(xiàn)要求 PostgreSQL 知道存儲(chǔ)設(shè)備的速度。

讓我們把討論的話題放回到I/O優(yōu)先。由于請(qǐng)求隊(duì)列的維護(hù)是通過(guò)I/O調(diào)度器實(shí)現(xiàn)的，大部分被PostgreSQL用戶所青睞的調(diào)度器都傾向于避免使用CFQ調(diào)度器（Completely Fair Queueing絕對(duì)公平調(diào)度器），或者說(shuō)根本就沒(méi)有實(shí)現(xiàn)I/O優(yōu)先機(jī)制。這還不是最糟的，甚至，那些提供了I/O優(yōu)先的地方還限制了請(qǐng)求隊(duì)列的長(zhǎng)度。一個(gè)大數(shù)據(jù)flush操作將會(huì)快速填滿隊(duì)列，這個(gè)時(shí)候I/O優(yōu)先就會(huì)失去大部分的效應(yīng)。如果沒(méi)有空間去容納這些請(qǐng)求隊(duì)列，一個(gè)高優(yōu)先級(jí)的請(qǐng)求將會(huì)失活，無(wú)法達(dá)到預(yù)期的高優(yōu)先?？磥?lái)，I/O優(yōu)先并不能解決問(wèn)題。

正確的解決之道看起來(lái)仍然是那樣的模糊和不著邊際。Ted說(shuō)如果PostgreSQL的開發(fā)者能提供那種通過(guò)運(yùn)行著的數(shù)據(jù)庫(kù)來(lái)構(gòu)建這種I/O模式的小程序，給出一種方法簡(jiǎn)單地去復(fù)現(xiàn)這些問(wèn)題，那么，內(nèi)核開發(fā)者就能嘗試多種不同的方式去尋求解決之道。這樣的程序可能類似于PostgreSQL的初始化配置腳本，但是一個(gè)單獨(dú)的小程序是內(nèi)核開發(fā)者社區(qū)更想要看到的。

雙緩沖技術(shù)

PostgreSQL需要去做屬于它自己的緩沖技術(shù)，因?yàn)槠溆泻芏嗲闆r下由于各種原因會(huì)使用I/O緩沖。這就會(huì)導(dǎo)致一個(gè)問(wèn)題：數(shù)據(jù)庫(kù)的數(shù)據(jù)往往會(huì)在內(nèi)存中被存儲(chǔ)兩次，一次是在PostgreSQL的緩沖區(qū)，另一次是在頁(yè)高速緩沖存儲(chǔ)器（page cache）。PostgreSQL在一定程度上極大地增加了內(nèi)存的使用次數(shù)，對(duì)于一個(gè)完整的系統(tǒng)是有害的。

大量的內(nèi)存浪費(fèi)行為應(yīng)該被有效地消除?？紤]這樣一個(gè)例子，在PostgreSQL的cache上有一個(gè)臟數(shù)據(jù)（dirty buffer），它比內(nèi)核所擁有的在頁(yè)高速緩沖存儲(chǔ)器上的數(shù)據(jù)要新。當(dāng)PostgreSQL刷新這個(gè)臟數(shù)據(jù)時(shí)，頁(yè)高速緩沖存儲(chǔ)器被重寫的這一重要過(guò)程將不會(huì)發(fā)生，因此，數(shù)據(jù)也就不同步了。在這種情況下，PostgreSQL要是能告訴內(nèi)核去移除在頁(yè)高速緩沖存儲(chǔ)器上相應(yīng)的頁(yè)就能好了，可是，現(xiàn)實(shí)就是，現(xiàn)在沒(méi)有好的API能做這件事。據(jù)安德魯（Andres）說(shuō)調(diào)用fadvise()函數(shù)的FADV_DONTNEED參數(shù)是可以的，實(shí)際上，這將引發(fā)指定的頁(yè)被讀出，幾乎沒(méi)人能很好地理解這種行為，但他們都贊成它不應(yīng)該用這種方式去工作。他們也不可以在沒(méi)有映射到文件處理前就使用madvise()函數(shù)，這樣做的話，可能大量正在工作著的進(jìn)程就會(huì)變得非常慢。

這種做法看起來(lái)不錯(cuò)，但同時(shí)也可能在反方向上移動(dòng)了一些頁(yè)，PostgreSQL可能想要從它自己的緩沖器中移除一個(gè)干凈的頁(yè)，但是卻在頁(yè)高速緩沖器里留下了一份拷貝?？赡艿那闆r，或許是一個(gè)實(shí)際上沒(méi)有引發(fā)I/O的特殊的寫操作，或許是一個(gè)將物理頁(yè)面轉(zhuǎn)換成頁(yè)高速緩沖器的系統(tǒng)調(diào)用。這些在表面上的討論是挺多的，但是卻沒(méi)有那一部分的討論是能給出確切的結(jié)論的。

復(fù)歸

對(duì)于PostgreSQL的用戶來(lái)說(shuō)另外一個(gè)問(wèn)題是經(jīng)常遇到的，在最近的一些內(nèi)核特性可能造成了的執(zhí)行性能上的問(wèn)題。舉個(gè)例子，透明大型分頁(yè)（transparent Huge page）特性對(duì)于PostgreSQL的工作負(fù)載來(lái)說(shuō)沒(méi)有任何好處，而且它還明顯地變慢了。顯然，大量時(shí)間都被用在那些努力運(yùn)行著的嚴(yán)密代碼上了，但是它們卻沒(méi)有真正產(chǎn)生空閑大型分頁(yè)（Huge page）。 于是，在許多的系統(tǒng)中，當(dāng)透明大型分頁(yè)（transparent Huge page）功能被關(guān)掉，可怕的性能問(wèn)題就簡(jiǎn)單地消失了。

Mel Gorman回答：如果壓縮正在損害性能，這將是一個(gè)缺陷。話雖如此，他在相當(dāng)長(zhǎng)的一段時(shí)間內(nèi)沒(méi)有發(fā)現(xiàn)任何透明大型分頁(yè)的缺陷。還有就是，他說(shuō)，已經(jīng)發(fā)布了一個(gè)限制進(jìn)程數(shù)量的補(bǔ)丁，該補(bǔ)丁能在任何給定的時(shí)間內(nèi)執(zhí)行壓縮。不過(guò)，這個(gè)補(bǔ)丁的代碼并沒(méi)有被合并，因?yàn)闆](méi)有人的工作負(fù)載曾經(jīng)遇到因太多進(jìn)程運(yùn)行壓縮而引發(fā)問(wèn)題。他認(rèn)為，也許是時(shí)候重新審視那個(gè)特定的補(bǔ)丁。

另一個(gè)痛點(diǎn)來(lái)源于區(qū)域回收功能，即使整個(gè)系統(tǒng)并不缺乏內(nèi)存，該功能也將在內(nèi)核中從一些區(qū)域回收頁(yè)。區(qū)域回收減慢了PostgreSQL的工作負(fù)載。通常***是在PostgreSQL服務(wù)器上簡(jiǎn)單的禁用此功能。Andres指出他已經(jīng)作為顧問(wèn)多次處理和區(qū)域回收有關(guān)的性能問(wèn)題。這對(duì)他來(lái)說(shuō)是一個(gè)很好的賺錢方式。不過(guò)如果能修復(fù)這些問(wèn)題，這將是一件好事。

Mel 說(shuō)，區(qū)域回收模式是在假設(shè)系統(tǒng)中所有進(jìn)程都納入到一個(gè)單一的NUMA節(jié)點(diǎn)下而寫的。這個(gè)假設(shè)已經(jīng)不再有意義了；它很過(guò)時(shí)了，他說(shuō)，這個(gè)選項(xiàng)的默認(rèn)值改為“off”?？雌饋?lái)房間里沒(méi)人反對(duì)這個(gè)想法，所以可能會(huì)在不久的將來(lái)發(fā)生一點(diǎn)變化。

PostgreSQL的開發(fā)者指出，在一般情況下，內(nèi)核升級(jí)往往是可怕的。Linux內(nèi)核的性能特點(diǎn)在一個(gè)發(fā)布版到下一個(gè)版本之間往往有很大的不同；這使升級(jí)成了一個(gè)不確定的事情。有些關(guān)于尋找運(yùn)行PostgreSQL基準(zhǔn)的新內(nèi)核的討論，但沒(méi)有得到明確結(jié)論。作為一個(gè)整體，雖然，這兩個(gè)項(xiàng)目的開發(fā)者高興怎么談話出來(lái)；如果沒(méi)有其他的事，這代表了兩個(gè)項(xiàng)目之間通信的一種新高度。

關(guān)于PostgreSQL痛點(diǎn)的解決方案是什么就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。