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

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

[[111142]] 

同步緩慢

***個(gè)被描述的問題是關(guān)于數(shù)據(jù)如何從緩沖區(qū)高速緩存保存到磁盤上。PostgreSQL 使用了一種形式的日志記錄，他們稱之為“預(yù)寫式日志”。變化之處首先寫入到日志中；一旦日志安全的保存在磁盤上，主要的數(shù)據(jù)庫塊就能被回寫。這個(gè)工作中很多都通過一個(gè)“檢查點(diǎn)”進(jìn)程來完成；它寫入日志條目，之后將一批數(shù)據(jù)寫回到磁盤上的各種文件中。這種帶有日志能力的寫操作相對而言小而連續(xù)；他們的工作效果不錯(cuò)，并且，據(jù) Andres 所說，PostgreSQL 的開發(fā)者對系統(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() 來確保數(shù)據(jù)被安全的寫入，并且所有這些被調(diào)節(jié)后的寫操作被立即推送到請求隊(duì)列時(shí)，就導(dǎo)致了 I/O 風(fēng)暴。據(jù)他們說，問題不是因?yàn)?fsync() 太慢，而是它太快了。它導(dǎo)出如此多的數(shù)據(jù)到 I/O 系統(tǒng)，以至于其它任何事情，包括應(yīng)用程序的讀請求等，都被阻塞住。這為用戶帶來了痛苦，同樣也為 PostgreSQL 的開發(fā)者帶來了痛苦。

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

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

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

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

雙緩沖技術(shù)

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

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

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

復(fù)歸

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

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

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

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

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

英文原文：PostgreSQL pain points

譯文鏈接：http://www.oschina.net/translate/postgresql-pain-points