硬件和軟件信息
CPU: Intel(R) Xeon(R) CPU E5-2683 v3 @ 2.00GHz 2 sockets / 28 cores / 56 threads
內存: 256GB of RAM
存儲: SAMSUNG SM863 1.9TB Enterprise SSD
操作系統: centos 7
文件系統: xfs
shared_buffers
定義了用於共享存儲器緩衝區的存儲器PostgreSQL使用量。這可以說是其最重要的設置，往往比（或好或壞）到MySQL的innodb_buffer_pool_size。最大的區別，如果我們敢於比較的shared_buffers緩衝池，是InnoDB的繞過操作系統的緩存直接訪問（讀取和寫入）的底層存儲子系統的數據，而PostgreSQL的沒有。
這是否意味着PostgreSQL裏面的“雙緩衝”，首先裝載數據從磁盤到操作系統的緩存來然後做這些網頁的副本進入的shared_buffers區域？是。
這是否“雙緩衝”讓PostgreSQL的不如InnoDB和MySQL的內存管理方面？不，我們將討論爲什麼這是一個跟進博客文章的情況。現在它足以說明實際性能取決於工作負載（讀取和寫入混合），“熱數據”（即最常訪問和修改數據集的部分），以及如何經常檢查點的大小發生。
我們該如何選擇了的shared_buffers以優化性能的PostgreSQL設置
由於這些因素，的shared_buffers設置的RAM或幻數“8GB”的25％的記錄建議式是幾乎不理想的。似乎是什麼好理由，不過，是這樣的：
如果你可以在內存中適應整個你的“熱數據”，則專大部分的內存來的shared_buffers不負有心人很好，這使得PostgreSQL的表現爲接近的內存數據庫成爲可能。
如果你的“熱數據”的大小超過你的服務器有可用的內存量，那麼你可能會更好用更小的shared_buffers區域合作，更多地依賴於操作系統的緩存。
對於這個基準，考慮到我們使用的選項，我們發現，專75％的所有可用內存來的shared_buffers是理想的。這足以適應整個“熱數據”，仍然留下足夠的內存用於OS操作，手柄連接和一切。
work_mem
該設置定義可以由每個查詢（未會話），用於內部排序操作（如ORDER BY和DISTINCT）中使用的存儲器量，以及哈希表（例如，執行基於散列的聚合時）。除此之外，PostgreSQL的數據移動到臨時磁盤文件。我們面臨的挑戰通常在這裏找到一個很好的平衡。我們要避免使用臨時磁盤文件，它們會減慢查詢完成，進而可能導致爭。但我們不希望過度使用內存，甚至可能導致OOM;當是不是真的需要它與work_mem高價值的工作可能是破壞性的。
我們分析了sysbench的-TPCC產生的工作量，並與一些驚喜發現，work_mem不會在這裏發揮作用，考慮已執行的查詢。所以我們一直4MB的默認值。請注意，這是很少在生產工作負載的情況下，所以它總是盯緊該參數是非常重要的。
random_page_cost
此設置規定，非連續牽強磁盤頁面將有成本，而且直接影響到查詢規劃決策。使用高等待時間的存儲時，如旋轉磁盤用保守的值會是特別重要的。這不是我們的情況，因此我們有能力平衡random_page_cost到seq_page_cost。所以，我們這個參數設置爲1，那麼從4默認值了。
wal_level, max_wal_senders and archive_mode
要設置流複製wal_level需要被設置爲至少“replica”，archive_mode必須啓用。這個裝置的WAL數據產生量增加顯著相比使用默認設置時這些參數，這反過來又影響到IO。然而，我們認爲這些與生產環境的初衷。
wal_compression
對於此工作負載，我們觀察到總的 WALs 大小爲 3359 GB，禁用wal_compression，1962 GB wal_compression。我們啓用wal_compression來減少 IO （以及最重要的是寫入磁盤的 WAL 文件）的數量（以及最重要的速率），但犧牲了一些額外的 CPU 週期。這被證明是非常有效的，因爲我們有多餘的CPU可用。
checkpoint_timeout、checkpoint_completion_target和max_wal_size
我們將checkpoint_timeout設置爲 1 小時，checkpoint_completion_target 設置爲 0.9。這意味着每 1 小時強制一個檢查點，並且在下一個檢查點之前有 90% 的時間來傳播寫入。但是，當生成 wal max_wal_size時，也會強制使用檢查點。通過"sysbench-tpcc"工作負載的這些參數，我們看到每 1 小時有 3 到 4 個檢查點。這特別是因爲生成的 LL 數量。
在生產環境中，我們始終建議您在關閉 PostgreSQL 之前執行手動 CHECKPOINT，以便更快地重新啓動（恢復）時間。在此背景下，發佈手動 CHECKPOINT 花了我們 1 到 2 分鐘的時間，之後我們只需大約 4 秒即可重新啓動 PostgreSQL。請注意，在我們的測試環境中，需要時間重新啓動 PostgreSQL 不是問題，因此使用此檢查點速率對我們有利。但是，如果您負擔不起幾分鐘的崩潰恢復時間，則始終建議強制更頻繁地執行檢查點，即使代價是性能下降。
full_page_writes、fsync 和synchronous_commit
我們將所有這些參數設置爲 ON 以滿足 ACID 屬性。
autovacuum
我們啓用了正在後臺進行 autovacuum 和其他 vacuum 設置，以確保真空。
我們將討論保持在生產環境中啓用 autovacuum，以及以其他方式這樣做的危險性，在一個單獨的職位的重要性。
10小時sysbench-TPCC的後生成WAL的（事務日誌）的量
在我們開始討論數字需要強調的是，我們開始之前sysbench的啓用wal_compression是很重要的。
如我們上面提到的，用“wal_compression”設定爲OFF產生的WAL的量爲多種具有壓縮啓用時比產生WAL量的兩倍。
我們觀察到，使wal_compression導致增加21％TPS。難怪，生產WAL的對IO的重要影響：以至於它是非常常見的發現的PostgreSQL服務器與僅WAL專用存儲。
因此，爲了強調這一事實，wal_compression可以通過額外的CPU使用率的費用節約IO受益寫密集型工作負載是很重要的。
爲了找出WAL的10小時後產生的總金額，我們注意到在WAL從我們開始測試前和測試結束後偏移：
WAL Offset before starting the sysbench-tpcc ⇒ 2C/860000D0
WAL Offset after 10 hours of sysbench-tpcc ⇒ 217/14A49C50
和減去一個來自另一個使用pg_wal_lsn_diff，如下所示：
postgres=# SELECT pg_size_pretty(pg_wal_lsn_diff('217/14A49C50','2C/860000D0'));
pg_size_pretty
----------------
1962 GB
(1 row)
1962年GB WAL的10小時以上生產事務日誌的一個相當大的量，考慮到我們已經啓用wal_compression。
我們設想利用一個單獨的磁盤來存儲WAL多少更多的事務日誌專用存儲將有利於整體性能，找出。
但是，我們希望用Vadim 曾用他以前的測試相同的硬件保持，所以決定在此。
Crash unsafe parameters
設置 full_page_writes ， FSYNC 和 synchronous_commit 爲OFF可以加速性能，但它總是死機不安全，
除非我們有到位足夠的備份來考慮這些需求。例如，如果您使用的是有一個日誌文件系統COW，
你可能會被罰款與設置爲OFF full_page_writes。這可能不是的，雖然時間真正100％。
然而，我們還是想分享在段落中提到以上作爲參考崩潰不安全的參數結果。
PostgreSQL的sysbench tpcc運行10小時後的結果，具有默認、崩潰安全和崩潰不安全參數
考慮到上述每種情況，我們在運行sysbench tpcc 10小時後獲得的最終數字如下：
| 參數 |
TPS |
| Default / Untuned |
1978.48 |
| Tuned (crash safe) |
5736.66 |
| Tuned (crash unsafe) |
7881.72 |
我們想得到這些數字嗎？是和不是。
當然，我們希望一個經過適當調整的服務器能夠比一個使用默認設置運行的服務器有更好的性能，但是我們不能說我們希望它比默認設置運行的服務器好三倍（2.899）。由於PostgreSQL使用了OS緩存，特別是對共享緩衝區的優化並不總是會產生如此顯著的影響。相比之下，調整MySQL的InnoDB緩衝池幾乎總是有區別的。對於PostgreSQL的高性能，它取決於工作負載。在這種情況下，對於sysbench tpcc基準測試，調整共享緩衝區肯定會有所不同。
另一方面，在使用崩潰不安全設置時，體驗額外的速度級（4倍）並不令人驚訝。
以下是PostgreSQL插入性能調整基準測試結果的另一種視圖：
