Linux 調優以提高 PostgreSQL 性能。 伊利亞·科斯莫傑米揚斯基

Ilya Kosmodemyansky 2015 年報告「Linux 調優以提高 PostgreSQL 效能」的文字記錄

免責聲明：我注意到這份報告的日期是 2015 年 4 月——已經過去 9.4 年多了，已經過去了很多時間。 報告中討論的4版本不再受支援。 在過去 5 年裡，PostgreSQL 發布了 15 個新版本，Linux 核心也發布了 XNUMX 個版本。 如果您重寫這些段落，您最終會得到不同的報告。 但這裡我們考慮對 PostgreSQL 進行基本的 Linux 調優，這在今天仍然具有現實意義。

我叫伊利亞‧科斯莫傑米揚斯基。 我在 PostgreSQL 顧問公司工作。 現在我將談談如何使用 Linux 來處理一般資料庫，特別是 PostgreSQL，因為原理非常相似。

我們會聊什麼？ 如果您與 PostgreSQL 進行通信，那麼在某種程度上您需要成為 UNIX 管理員。 這是什麼意思？ 如果我們比較 Oracle 和 PostgreSQL，那麼在 Oracle 中，您需要是 80% 的 DBA 資料庫管理員和 20% 的 Linux 管理員。

對於 PostgreSQL，情況稍微複雜一點。 使用 PostgreSQL，您需要更了解 Linux 的工作原理。 同時，在機車後面跑一點，因為最近一切都更新得很好。 新核心的發布、新功能的出現、效能的提升等等。

我們為什麼要談Linux？ 根本不是因為我們正在參加 Linux 會議 Peter，而是因為在現代條件下，Linux 是使用資料庫（尤其是 PostgreSQL）最合理的作業系統之一。 因為不幸的是，FreeBSD 正在朝著一些非常奇怪的方向發展。 性能和許多其他方面都會出現問題。 PostgreSQL 在 Windows 上的效能通常是一個單獨的嚴重問題，因為 Windows 沒有與 UNIX 相同的共享內存，而 PostgreSQL 則與此相關，因為它是一個多進程系統。

我認為每個人都對 Solaris 這樣的外來事物不太感興趣，所以我們走吧。

現代 Linux 發行版有超過 1 個 syctl 選項，具體取決於您建立核心的方式。 同時，如果我們觀察不同的堅果，我們可以透過多種方式進行調整。 有關於如何安裝它們的檔案系統參數。 如果您對如何啟動有疑問：在 BIOS 中啟用什麼、如何設定硬體等。

這是一個非常大的捲，可以在幾天內討論，而不是在一篇簡短的報告中，但現在我將重點關注重要的事情，如何避免那些保證會阻止您在Linux 上使用資料庫的Rake，如果您不要糾正它們。 同時，重要的一點是許多預設參數並未包含在對資料庫正確的設定中。 也就是說，預設情況下它會工作得很差或根本不工作。

Linux 中有哪些傳統的調校目標？ 我認為既然你們都在處理Linux管理，那麼就沒有特別需要解釋什麼是目標。

您可以調整：

• 中央處理器。
• 記憶。
• 存儲。
• 其他。 我們將在最後吃零食時討論這個問題。 例如，甚至節能政策等參數也會以一種非常不可預測且不是最令人愉快的方式影響效能。

PostgreSQL 和資料庫的具體特徵是什麼？ 問題是你無法調整任何一個單獨的堅果並看到我們的性能顯著提高。

是的，有這樣的小工具，但資料庫是一個複雜的東西。 它與伺服器擁有的所有資源進行交互，並且更願意進行最充分的交互。 如果你看看 Oracle 目前關於如何使用主機作業系統的建議，你會發現這就像蒙古太空人的笑話一樣——餵狗，不要碰任何東西。 讓我們將所有資源交給資料庫，資料庫本身會整理所有內容。

原則上，某種程度上情況與 PostgreSQL 完全相同。 不同之處在於資料庫還無法為自己取得所有資源，也就是在 Linux 層級的某個地方您需要自己整理所有資源。

主要思想不是選擇單一目標並開始調整它，例如記憶體、CPU 或類似的東西，而是分析工作負載並嘗試盡可能提高吞吐量，以便優秀的程式設計師創建它的負載對於我們，包括我們的用戶。

這是一張圖片來解釋它是什麼。 有 Linux 作業系統緩衝區、共享記憶體和 PostgreSQL 共享緩衝區。 與 Oracle 不同，PostgreSQL 僅透過核心緩衝區直接工作，即，為了使磁碟中的頁面進入其共享內存，它必須經過核心緩衝區並返回，情況完全相同。

磁碟位於該系統下。 我把它畫成磁碟。 事實上，可能還有RAID控制器等。

這種輸入輸出以某種方式透過這件事發生。

PostgreSQL 是一個經典的資料庫。 裡面有一頁。 所有輸入和輸出都使用頁面進行。 我們透過頁面將區塊提升到記憶體中。 如果沒有發生任何事情，我們只是讀取它們，然後它們逐漸從快取、共享緩衝區中消失，最後回到磁碟上。

如果我們取代某處的某些內容，那麼整個頁面都會被標記為髒。 我在這裡用藍色標記它們。 這意味著該頁面必須與區塊儲存同步。 也就是說，當我們弄髒時，我們在 WAL 中建立了一個條目。 在某個美妙的時刻，一種叫做檢查點的現像出現了。 而這份日誌中記錄了他已經到達的資訊。 這表示此時共用緩衝區中的所有髒頁都透過核心緩衝區使用 fsync 與儲存磁碟同步。

為什麼要這樣做？ 如果我們失去電壓，那麼我們就不會出現所有資料都遺失的情況。 每個人都告訴我們的持久記憶體到目前為止在資料庫理論中都是如此——這是一個光明的未來，我們當然會為之奮鬥並且我們喜歡它，但目前它們的壽命還剩負 20 年。 當然，所有這一切都需要監控。

最大化吞吐量的任務是在所有這些階段進行微調，以便一切快速來回移動。 共享記憶體基本上是一個頁面快取。 在 PostgreSQL 中，我們發送了一個選擇查詢或其他東西，它從磁碟檢索這些資料。 他們最終進入共享緩衝區。 因此，為了更好地工作，必須有大量的記憶體。

為了讓這一切順利快速地工作，您需要在各個階段正確配置作業系統。 並選擇平衡的硬件，因為如果某個地方不平衡，那麼您可以製造大量內存，但不會以足夠的速度提供服務。

讓我們逐一討論這些要點。

為了讓這些頁面更快來回移動，您需要實現以下目標：

• 首先，你需要更有效地利用記憶。
• 其次，頁面從記憶體到磁碟的轉換應該更有效率。
• 第三，要有好的磁碟。

如果伺服器中有 512 GB RAM，而所有這些記憶體最終都位於沒有任何快取的 SATA 硬碟上，那麼整個資料庫伺服器就不僅僅是一個南瓜，而是一個帶有 SATA 介面的南瓜。 你會直接遇到它。 沒有什麼能拯救你。

關於第一點記憶，有三件事會讓生活變得非常困難。

第一個是 NUMA。 NUMA 是為了提高性能而設計的。 根據工作負載，可以優化不同的事情。 在目前的新形式中，它對於密集使用頁面快取共享緩衝區的資料庫等應用程式來說並不是很好。

簡而言之。 如何判斷 NUMA 是否有問題？ 你有某種不愉快的敲擊聲，突然某個CPU超載了。 同時，您分析 PostgreSQL 中的查詢，發現沒有任何類似的東西。 這些查詢不應該如此佔用 CPU 資源。 你可以抓住這個很長一段時間。 從一開始就使用如何為 PostgreSQL 設定 NUMA 的正確建議會更容易。

究竟發生了什麼事？ NUMA 代表非統一記憶體存取。 重點是什麼？ 你有一個CPU，旁邊有它的本地記憶體。 這種記憶體互連可以從其他 CPU 調出記憶體。

如果你跑 numactl --hardware，那麼你就會得到這麼大的一張紙。 除此之外，還有一個距離場。 會有數字——10-20，類似的東西。 這些數字只不過是獲取此遠端記憶體並在本地使用它的跳數。 原則上，這是一個好主意。 這可以在一定範圍的工作負載下大大提高效能。

現在想像一下，您有一個 CPU 首先嘗試使用其本地內存，然後嘗試通過互連拉出另一個內存以進行某些操作。 這個 CPU 獲得整個 PostgreSQL 頁面快取 - 就是這樣，一些 GB。 你總是會遇到最壞的情況，因為在 CPU 上，該模組本身的記憶體通常很少。 所有提供服務的記憶體都經過這些互連。 事實證明它緩慢而悲傷。 並且為該節點提供服務的處理器不斷過載。 而且這種記憶體的存取時間很差、很慢。 如果您將其用於資料庫，這是您不希望出現的情況。

因此，對於資料庫來說，更正確的選擇是讓 Linux 作業系統根本不知道那裡發生了什麼。 這樣它就可以像它一樣存取記憶體。

這是為什麼？ 似乎應該反過來才對。 發生這種情況的原因很簡單：我們需要大量記憶體用於頁面快取 - 數十、數百 GB。

如果我們分配所有這些並將資料緩存在那裡，那麼使用快取的收益將明顯大於這種棘手的記憶體存取的收益。 與使用 NUMA 更有效地存取記憶體相比，我們將受益匪淺。

因此，目前有兩種方法，直到光明的未來到來，資料庫本身無法弄清楚它正在哪些CPU上運行以及需要從哪裡提取資料。

因此，正確的做法是完全停用 NUMA，例如，重新啟動時。 在大多數情況下，獎金的數量級很大，以至於根本不存在哪個更好的問題。

還有另一種選擇。 我們比第一個更頻繁地使用它，因為當客戶向我們尋求支援時，重新啟動伺服器對他來說是一件大事。 他在那裡有生意。 他們會因為 NUMA 而遇到問題。 因此，我們嘗試以比重啟更具侵入性的方式停用它，但要小心檢查它是否已停用。 因為，如經驗所顯示的，我們在父 PostgreSQL 行程上停用 NUMA 是件好事，但它根本沒有必要運作。 我們需要檢查一下她是否真的關機了。

羅伯特·哈斯 (Robert Haas) 發表了一篇很好的文章。 這是 PostgreSQL 提交者之一。 所有低階內臟的主要開發者之一。 如果您點擊這篇文章中的鏈接，他們會描述幾個關於 NUMA 如何讓人們的生活變得困難的豐富多彩的故事。 看一下，研究系統管理員清單，了解需要在伺服器上配置哪些內容才能使我們的資料庫正常運作。 這些設定需要記下來並檢查，否則效果不會很好。

請注意，這適用於我將討論的所有設定。 但通常資料庫都是以主從模式進行收集，以實現容錯。 不要忘記在從機上進行這些設置，因為有一天你會發生意外，你會切換到從機，它會成為主機。

在緊急情況下，當一切都非常糟糕時，你的電話不斷地響著，你的老闆拿著大棒跑過來，你將沒有時間考慮檢查。 結果可能是相當災難性的。

下一點是大頁面。 大頁面很難單獨測試，而且這樣做沒有意義，儘管有基準測試可以做到這一點。 它們很容易被谷歌搜尋到。

重點是什麼？ 您有一台不是很昂貴的伺服器，具有大量 RAM，例如超過 30 GB。 您不使用大頁面。 這意味著您在記憶體使用方面肯定有開銷。 而這種開銷遠非最令人愉快的。

這是為什麼？ 發生什麼事了？ 作業系統將記憶體分配為小塊。 太方便了，歷史上就是這樣發生的。 如果我們詳細討論的話，作業系統必須將虛擬位址轉換為實體位址。 而這個過程並不是最簡單的，因此作業系統將這個操作的結果快取在Translation Lookaside Buffer（TLB）中。

而且由於TLB是一個緩存，因此緩存固有的所有問題都會在這種情況下出現。 首先，如果你有很多 RAM 並且都是以小塊的形式分配的，那麼這個緩衝區就會變得非常大。 如果快取很大，則搜尋速度會更慢。 開銷是健康的，它本身會佔用空間，即 RAM 被不正確的東西消耗。 這次。

第二 - 在這種情況下快取成長得越多，快取未命中的可能性就越大。 並且該快取的效率隨著其大小的增加而迅速下降。 因此，作業系統想出了一個簡單的方法。 它在 Linux 中已經使用了很長時間。 不久前它出現在 FreeBSD 中。 但我們談論的是Linux。 這些是巨大的頁面。

這裡應該指出的是，大頁面作為一個想法，最初是由包括 Oracle 和 IBM 在內的社群推動的，即資料庫製造商強烈認為這對資料庫也很有用。

這怎麼能和 PostgreSQL 交上朋友呢？ 首先，必須在 Linux 核心中啟用大頁。

其次，它們必須由 sysctl 參數明確指定 - 有多少個。 這裡的數字來自一些舊伺服器。 您可以計算有多少個共用緩衝區，以便可以容納大頁面。

如果您的整個伺服器專用於 PostgreSQL，那麼一個好的起點是將 25% 的 RAM 分配給共享緩衝區，或者如果您確定您的資料庫肯定適合這 75%，則分配 75%。 起點一。 考慮一下，如果您有 256 GB 的 RAM，那麼相應地，您將擁有 64 GB 的大緩衝區。 大約計算一些餘量 - 該數字應設定為多少。

在 9.2 版本之前（如果我沒記錯的話，從 8.2 版本開始），可以使用第三方函式庫將 PostgreSQL 與大頁面連接起來。 並且應該始終這樣做。 首先，您需要核心能夠正確分配大頁面。 其次，以便與它們一起工作的應用程式可以使用它們。 它不會只是這樣使用。 由於 PostgreSQL 以系統 5 風格分配內存，因此可以使用 libhugetlbfs 來完成 - 這是庫的全名。

在 9.3 中，PostgreSQL 在使用記憶體時的效能得到了提高，並且放棄了 system 5 記憶體分配方法。 每個人都很高興，因為否則你嘗試在一台機器上運行兩個 PostgreSQL 實例，他說我沒有足夠的共享記憶體。 他說 sysctl 需要糾正。 而且有這麼一個sysctl還需要重啟等等。總的來說，大家都很高興。 但是mmap記憶體分配打破了大頁的使用。 我們的大多數客戶都使用大型共享緩衝區。 我們強烈建議不要切換到 9.3，因為那裡的開銷開始以良好的百分比計算。

但社區注意到了這個問題，在 9.4 中他們很好地重做了這個事件。 在 9.4 中，postgresql.conf 中出現了一個參數，您可以在其中啟用 try、on 或 off。

嘗試是最安全的選擇。 當PostgreSQL啟動時，當它分配共享記憶體時，它會嘗試從大頁中取得這塊記憶體。 如果不起作用，則會回滾到正常選擇。 如果你有 FreeBSD 或 Solaris，那麼你可以嘗試一下，它總是安全的。

如果打開，則如果無法從大頁面中進行選擇，則它根本不會啟動。 這裡已經是關於誰和什麼更好的問題了。 但如果您嘗試過，請檢查是否確實突出顯示了您需要的內容，因為存在很大的出錯空間。 目前此功能僅適用於 Linux。

在我們進一步討論之前，還有一個小註釋。 透明大頁還不是關於 PostgreSQL 的。 他無法正常使用它們。 對於此類工作負載，使用透明大頁，當需要大塊共享記憶體時，只有非常大的容量才能帶來好處。 如果您有 TB 的內存，那麼這可能會發揮作用。 如果我們談論的是更日常的應用程序，當您的機器上有 32、64、128、256 GB 內存時，那麼通常的大頁面就可以了，我們只需禁用透明即可。

最後一個關於記憶的事情與成果沒有直接關係，它真的可以毀掉你的人生。 伺服器不斷交換的事實將極大地影響所有吞吐量。

這在很多方面都會令人非常不愉快。 主要問題是現代核心的行為與舊版 Linux 核心略有不同。 而這個東西踩起來相當不愉快，因為當我們談論某種與swap有關的工作時，它就以OOM殺手的不合時宜的到來而告終。 而 OOM-killer 沒有及時到達並丟棄了 PostgreSQL，令人不快。 每個人都會知道這一點，即直到最後一個用戶。

發生了什麼事？ 你有大量的內存，一切都運行良好。 但由於某種原因，伺服器掛在交換中並因此變慢。 看起來內存很多，但是卻發生了這種情況。

先前，我們建議將 vm.swappiness 設為零，即停用交換。 以前，32 GB RAM 和相應的共享緩衝區似乎是一個巨大的數字。 交換的主要目的是當我們摔倒時有一個地方可以扔掉外殼。 而且也不再特別滿足了。 然後你打算用這個外殼做什麼呢？ 這是一項不太清楚為什麼需要交換的任務，尤其是對於這樣大的大小。

但在更現代的核心第三版中，行為發生了變化。 如果你將交換設定為零，即關閉它，那麼遲早，即使還有一些 RAM 剩餘，OOM 殺手也會來找你殺死最密集的消費者。 因為他會考慮到這麼大的工作量我們還剩下一點點，我們就會跳出來，就是不去敲定係統流程，而是去敲定一些不太重要的東西。 這個不太重要的角色是共享記憶體的密集消耗者，即郵政局長。 在那之後，如果不需要修復基地就好了。

因此，據我所知，現在默認情況下，大多數發行版都在 6 左右，即您應該在什麼時候開始使用交換，具體取決於剩餘內存量。 我們現在建議設定 vm.swappiness = 1，因為這實際上會將其關閉，但不會產生與意外到達並殺死整個事件的 OOM 殺手相同的效果。

下一步是什麼？ 當我們談論資料庫的效能並逐漸轉向磁碟時，每個人都開始抓頭。 因為磁碟慢、記憶體快這個道理大家從小就熟悉。 而且大家都知道資料庫會出現磁碟效能問題。

與檢查點峰值相關的主要 PostgreSQL 效能問題不會發生，因為磁碟速度很慢。 這很可能是由於記憶體和磁碟頻寬不平衡造成的。 然而，它們在不同的地方可能並不平衡。 PostgreSQL未配置、作業系統未配置、硬體未配置、硬體不正確。 只有當一切都按其應有的方式發生時，即沒有負載，或者設定和硬體選擇良好時，這個問題才不會發生。

它是什麼以及它看起來像什麼？ 通常使用 PostgreSQL 的人都會不只一次涉及這個問題。 我會解釋一下。 正如我所說，PostgreSQL 定期建立檢查點以將共用記憶體中的髒頁轉儲到磁碟。 如果我們有大量共享內存，那麼檢查點開始對磁碟產生強烈影響，因為它會使用 fsync 轉儲這些頁面。 它到達核心緩衝區並使用 fsync 寫入磁碟。 如果該業務量很大，那麼我們可以觀察到一個令人不快的效果，即磁碟利用率非常高。

這裡我有兩張照片。 我現在將解釋它是什麼。 這是兩個時間相關​​的圖。 第一張圖是磁碟利用率。 此時它幾乎達到了 90%。 如果您的實體磁碟出現資料庫故障，且 RAID 控制器利用率為 90%，那麼這是個壞消息。 這意味著再多一點，就會達到 100，I/O 就會停止。

如果您有磁碟陣列，那麼情況會略有不同。 這取決於它的配置方式、它是什麼類型的陣列等等。

同時，這裡配置了來自內部 postgres 視圖的圖表，它告訴我們檢查點是如何發生的。 這裡的綠色顯示了有多少緩衝區，這些髒頁，在那一刻到達了這個檢查點進行同步。 這是您需要了解的主要內容。 我們看到這裡有很多頁面，在某個時刻我們撞到了木板，也就是說，我們寫了又寫，這裡磁碟系統顯然非常繁忙。 而我們的檢查點對磁碟的影響非常大。 理想情況下，情況應該更像這樣，即我們這裡的錄音較少。 我們可以透過設定來修復它，以便它繼續這樣。 也就是說，回收量很小，但是我們在這裡寫一些東西。

需要做什麼來克服這個問題？ 如果你已經停止了資料庫下的IO，這表示所有前來滿足其請求的用戶都將等待。

如果你從Linux 的角度來看，如果你使用了良好的硬件，正確配置了它，正常配置了PostgreSQL，這樣就可以減少這些檢查點的頻率，隨著時間的推移將它們分散在彼此之間，那你就進入了預設的Debian 參數。 對於大多數 Linux 發行版，如下圖：vm.dirty_ratio=20，vm.dirty_background_ratio=10。

這是什麼意思？ 2.6 核心中出現了一個刷新惡魔。 Pdglush，取決於誰在使用哪一個，它從事後台丟棄內核緩衝區中的髒頁，並在無論如何都需要丟棄髒頁時丟棄，當後台丟棄沒有幫助時。

背景什麼時候來？ 當伺服器上可用總 RAM 的 10% 被核心緩衝區中的髒頁佔用時，會在背景呼叫一個特殊的註銷函數。 為什麼是背景呢？ 作為一個參數，它考慮了要註銷的頁數。 假設他註銷了 N 頁。 有一段時間這個東西睡著了。 然後她又來了，又影印了幾頁。

這是一個極為簡單的故事。 這裡的問題就像游泳池一樣，當水倒入一根管子時，它就會流入另一根管子。 我們的檢查點到達了，如果它發送了一些髒頁進行丟棄，那麼整個事情將逐漸從內核緩衝區 pgflush 中得到巧妙的解決。

如果這些髒頁繼續積累，它們會累積到20%，之後作業系統的優先順序就是將整個內容寫到磁碟上，因為電源將會失效，一切都會對我們不利。 例如，我們將丟失這些資料。

有什麼訣竅呢？ 訣竅在於，在現代世界中，這些參數分別佔機器上總 RAM 的 20% 和 10%，就您擁有的任何磁碟系統的吞吐量而言，它們絕對是巨大的。

假設您有 128 GB 的 RAM。 12,8 GB 到達您的磁碟系統。 無論你有什麼緩存，無論你有什麼陣列，它們都不會持續那麼久。

因此，我們建議您立即根據 RAID 控制器的功能調整這些數字。 我立即在這裡推薦了具有 512 MB 快取的控制器。

一切都被認為非常簡單。 您可以將 vm.dirty_background 以位元組為單位。 而這些設定取消了前面的兩項。 要嘛是預設的比例，要嘛啟動有字節的，那麼有字節的就可以了。 但由於我是 DBA 顧問，並且與不同的客戶合作，所以我會嘗試抽籤，因此，如果以位元組為單位，那就以位元組為單位。 沒有人能保證優秀的管理員不會向伺服器添加更多內存，重新啟動伺服器，並且數字將保持不變。 只需計算這些數字，以便一切都符合其中的保證。

如果你不適應會發生什麼事？ 我曾經寫過，任何沖水都會被有效地阻止，但實際上這是一個比喻。 作業系統有一個大問題 - 它有很多髒頁，因此客戶端生成的 IO 實際上已停止，即應用程式已向資料庫發送 sql 查詢，它正在等待。 它的任何輸入/輸出都是最低優先順序的，因為資料庫被檢查點佔用。 她什麼時候能完成還完全不清楚。 而當你實作了非後台刷新，就代表你所有的IO都被它佔用了。 在它結束之前，你什麼也做不了。

這裡還有兩點超出了本報告的範圍。 這些設定應該與 postgresql.conf 中的設定匹配，即檢查點設定。 並且您的磁碟系統必須經過充分配置。 如果 RAID 上有緩存，那麼它必須有電池。 人們購買具有良好快取的 RAID，但不帶電池。 如果你有RAID的SSD，那麼它們一定是伺服器的，那裡一定有電容。 這是詳細的清單。 此連結包含我有關如何在 PostgreSQL 中配置效能磁碟的報告。 那裡有所有這些清單。

還有什麼能讓生活變得非常困難呢？ 這是兩個參數。 它們相對較新。 預設情況下，它們可以包含在不同的應用程式中。 如果它們的開啟方式不正確，它們也會讓生活變得同樣困難。

有兩個相對較新的事物。 他們已經出現在了第三核心之中。 這是以奈秒為單位的 sched_migration_cost 和 sched_autogroup_enabled，預設為 XNUMX。

他們如何毀掉你的生活？ 什麼是 sched_migration_cost？ 在 Linux 上，調度程式可以將進程從一個 CPU 遷移到另一個 CPU。 而對於執行查詢的 PostgreSQL 來說，遷移到另一個 CPU 是完全不清楚的。 從作業系統的角度來看，當你在openoffice和terminal之間切換視窗時，這可能很好，但是 對於資料庫來說這是非常糟糕的。 因此，合理的策略是將migration_cost設定為某個大值，至少幾千納秒。

這對於調度程序意味著什麼？ 在此期間，可以認為該過程仍然是熱的。 也就是說，如果您有一個長時間運行的事務，並且已經做了很長時間的某件事，那麼調度程序就會理解這一點。 他將假設在超時過去之前，無需將此進程遷移到任何地方。 如果進程同時執行某些操作，那麼它不會被遷移到任何地方，它將安靜地在分配給它的 CPU 上工作。 結果非常好。

第二點是自動分組。 對於與現代資料庫無關的特定工作負載，有一個好主意 - 即按啟動進程的虛擬終端將進程分組。 這對於某些任務來說很方便。 實際上，PostgreSQL 是一個多進程系統，具有從單一終端運行的預分叉。 您有一個鎖編寫器、檢查點，並且所有客戶端請求將被分組到每個 CPU 的一個排程器。 他們會齊聲在那裡等待他自由，以便互相干擾，讓他忙得更久。 這是一個在這樣的負載情況下完全沒有必要的故事，因此需要將其關閉。

我的同事 Alexey Lesovsky 使用簡單的 pgbench 進行了測試，他將 migration_cost 增加了一個數量級並關閉了 autogroup。 壞硬體上的差異幾乎為 10%。 在 postgres 郵件列表上有一個討論，人們給出了類似的查詢速度變化的結果 影響50%。 這樣的故事還有很多。

最後，關於節能政策。 好消息是 Linux 現在可以在筆記型電腦上使用。 據說它會很好地耗盡電池。 但突然發現這也可能發生在伺服器上。

此外，如果您從某個託管商租用伺服器，那麼「好」託管商並不關心您是否有更好的效能。 他們的任務是確保盡可能有效地利用鐵。 因此，預設情況下他們可以在作業系統上啟用筆記型電腦省電模式。

如果你在資料庫負載很重的伺服器上使用這個東西，那麼你的選擇是 acpi_cpufreq + permormance。 即使使用 ondemand 也會出現問題。

Intel_pstate 是一個略有不同的驅動程式。 現在優先選擇這個，因為它更晚並且效果更好。

而且，相應地，州長只是表現。 點播、省電以及其他一切都與您無關。

如果啟用 powersave，解釋分析 PostgreSQL 的結果可能會相差幾個數量級，因為實際上資料庫下的 CPU 將以完全不可預測的方式運作。

預設可能包含這些項目。 仔細查看他們是否默認打開它。 這可能是一個很大的問題。

最後，我想對 PosgreSQL 諮詢 DBA 團隊的 Max Boguk 和 Alexey Lesovsky 表示感謝，他們每天都在這個問題上取得進展。 我們盡力為客戶提供最好的服務，讓一切都對他們有利。 就像航空安全說明一樣。 這裡的一切都是用血寫成的。 這些堅果中的每一個都是在某種問題的過程中發現的。 我很高興與您分享它們。

問題：

謝謝你！ 例如，如果一家公司想省錢，將資料庫和應用程式邏輯放在一台伺服器上，或者公司遵循微服務架構的流行趨勢，其中 PostgreSQL 在容器中運行。 有什麼訣竅呢？ Sysctl會全域影響整個核心。 我還沒有聽說過 sysctls 以某種方式虛擬化，以便它們在容器上單獨工作。 只有一個cgroup，那裡只有部分控制。 你怎麼能忍受這件事呢？ 或者如果您想要效能，那麼在單獨的硬體伺服器上執行 PostgreSQL 並對其進行調整？

我們透過大約三種方式回答了你的問題。 如果我們不是在談論可以調整的硬體伺服器等，那麼放鬆一下，沒有這些設定一切都會正常運作。 如果你有這樣的負載，你需要進行這些設置，那麼你會比這些設定更早來到iron伺服器。

問題是什麼？ 如果這是虛擬機，那麼您很可能會遇到很多問題，例如，在大多數虛擬機器上，磁碟的延遲非常不一致。 即使磁碟吞吐量很好，那麼失敗的 I/O 事務不會對檢查點時或寫入 WAL 時發生的平均吞吐量產生很大影響，那麼資料庫將會受到很大影響。 在遇到這些問題之前您會注意到這一點。

如果你在同一台伺服器上有NGINX，你也會遇到同樣的問題。 他將為共享記憶而戰。 而且您不會遇到此處描述的問題。

但另一方面，其中一些參數仍然與您相關。 例如，使用 sysctl 設定 dirty_ratio，這樣它就不會那麼瘋狂 - 無論如何，這都會有所幫助。 無論哪種方式，您都將與磁碟進行互動。 而且它會遵循錯誤的模式。 這通常是我所展示的參數的預設值。 無論如何，最好改變它們。

但NUMA可能會出現問題。 例如，VmWare 可以在完全相反的設定下與 NUMA 配合得很好。 在這裡你必須選擇 - 鐵製伺服器或非鐵製伺服器。

我有一個與 Amazon AWS 相關的問題。 他們預先配置了圖像。 其中之一稱為 Amazon RDS。 他們的作業系統有任何自訂設定嗎？

那裡有設置，但它們是不同的設置。 這裡我們根據資料庫如何使用這個東西來配置作業系統。 還有一些參數決定我們現在應該去哪裡，例如塑造。 也就是說，我們需要這麼多的資源，我們現在就把它們吃光了。 此後，Amazon RDS 會收緊這些資源，並且效能會下降。 有一些關於人們如何開始搞亂這個問題的故事。 有時甚至相當成功。 但這與作業系統設定無關。 這就像破解雲。 那是一個不同的故事。

為什麼透明大頁與Huge TLB相比沒有效果？

不要給。 這可以從很多方面來解釋。 但事實上他們根本不給。 PostgreSQL 的歷史是什麼？ 啟動時，它會分配一大塊共享記憶體。 它們是否透明完全無關緊要。 他們一開始就脫穎而出的事實說明了一切。 如果有大量記憶體並且需要重建shared_memory段，那麼透明大頁面將是相關的。 在 PostgreSQL 中，它只是在開始時被分配在一個巨大的區塊中，僅此而已，然後就沒有什麼特別的事情發生了。 當然，您可以使用它，但是當它重新分配某些內容時，有可能會損壞共享記憶體。 PostgreSQL 不知道這一點。

來源： www.habr.com