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

代縣網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,代縣網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為代縣1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的代縣做網(wǎng)站的公司定做！

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

PostgreSQL是一個很老的系統(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)歷的一些問題。

同步緩慢

第一個被描述的問題是關(guān)于數(shù)據(jù)如何從緩沖區(qū)高速緩存保存到磁盤上。PostgreSQL 使用了一種形式的日志記錄，他們稱之為“預(yù)寫式日志”。變化之處首先寫入到日志中；一旦日志安全的保存在磁盤上，主要的數(shù)據(jù)庫塊就能被回寫。這個工作中很多都通過一個“檢查點(diǎn)”進(jìn)程來完成；它寫入日志條目，之后將一批數(shù)據(jù)寫回到磁盤上的各種文件中。這種帶有日志能力的寫操作相對而言小而連續(xù)；他們的工作效果不錯，并且，據(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ì)列時，就導(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)程不需要帶寬時，應(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 操作時，優(yōu)先級沒有實(shí)施上。

Ric Wheeler 建議，PostgreSQL 開發(fā)者需要更好的控制他們寫入數(shù)據(jù)的速度；Chris Mason 補(bǔ)充說，當(dāng)產(chǎn)生 I/O 請求時，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ì)列的長度。一個大數(shù)據(jù)flush操作將會快速填滿隊(duì)列，這個時候I/O優(yōu)先就會失去大部分的效應(yīng)。如果沒有空間去容納這些請求隊(duì)列，一個高優(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的初始化配置腳本，但是一個單獨(dú)的小程序是內(nèi)核開發(fā)者社區(qū)更想要看到的。

雙緩沖技術(shù)

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

大量的內(nèi)存浪費(fèi)行為應(yīng)該被有效地消除?？紤]這樣一個例子，在PostgreSQL的cache上有一個臟數(shù)據(jù)（dirty buffer），它比內(nèi)核所擁有的在頁高速緩沖存儲器上的數(shù)據(jù)要新。當(dāng)PostgreSQL刷新這個臟數(shù)據(jù)時，頁高速緩沖存儲器被重寫的這一重要過程將不會發(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)程就會變得非常慢。

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

復(fù)歸

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

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

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

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

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

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

新聞標(biāo)題：PostgreSQL痛點(diǎn)的解決方案是什么
網(wǎng)站URL：http://www.rwnh.cn/article6/jgpiog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供云服務(wù)器、響應(yīng)式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站策劃、網(wǎng)站內(nèi)鏈、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)