什麼是Postgres的明智的基本OLTP配置？

Question

我們剛剛開始調查使用Postgres作爲我們系統的後端，它將與OLTP類型的工作負載一起使用：事務的> 95％（可能> 99％）將插入1行到4個單獨的表中，或更新1行。我們的測試機器在運行速度爲9.5.6（使用開箱即用的配置選項）的情況下運行在採用4核i7處理器的普通雲託管Windows VM和傳統7200 RPM磁盤上。這比我們定位的生產硬件慢得多，但是現在有用於找到我們基本設計的瓶頸。

我們最初的測試很令人沮喪。儘管insert語句本身運行速度相當快（組合執行時間大約爲2ms），但由於commit語句需要38 ms，因此總體事務時間大約爲40ms。此外，在一個簡單的3分鐘負載測試（5000個事務）期間，我們只看到每秒大約30個事務，而pgbadger報告在「提交」（平均38毫秒）中花費了3分鐘，而下一個最高語句是分別插入10（2ms）和3（0.6 ms）。在此測試中，postgres實例上的CPU與100g掛鉤

事實上，花在提交上的時間等於測試已用時間告訴我，不僅是提交序列化（不出意外，給出在這個系統上相對較慢的磁盤），但它在這段時間內消耗了一個cpu，這讓我感到驚訝。如果我們受到I/O限制，我會假設在CPU使用率非常低，使用率不高的情況下。

在做了一些閱讀之後，看起來使用異步提交可以解決很多這些問題，但是在崩潰/立即關閉時會造成數據丟失的警告。同樣，將事務組合到一個單獨的開始/提交塊中，或者使用多行插入語法也可以提高吞吐量。我們可以使用所有這些選項，但在傳統的OLTP應用程序中，它們都不會（您需要有快速的原子同步事務）。在一個4核心盒子上，每秒35個事務在20年前對於運行在比這個測試機器慢得多的硬件上的其他RDBM是不可接受的，這使得我認爲我們做錯了，因爲我確信Postgres能夠處理更高的工作量。

我環顧四周，但找不到一些常識性的配置選項，可以作爲調整Postgres實例的起點。有什麼建議麼？

Answer 1

儘管爲OLTP工作負載看到一些很好的啓動配置會很有趣，但我們已經解決了提交過程中不合理地高CPU的謎團。事實證明，它根本不是Postgres，而是Windows Defender經常掃描Postgres數據文件。設置我們承載測試服務器的虛擬機的團隊不瞭解我們需要後端配置，而不是用戶配置。

Answer 2

如果COMMIT是你的時間生豬，這可能意味着：

1. 您的系統榮譽的FlushFileBuffers系統調用，這是理所應當的。

2. 你的I/O速度很慢。

您可以通過在postgresql.conf –設置fsync = off測試這一點，但不會永遠做這在生產系統上。如果這樣可以提高性能，那麼您知道在實際上需要將數據寫入磁盤時，您的I/O系統非常慢。

PostgreSQL（或任何其他可靠的數據庫）在不犧牲數據持久性的情況下不會有任何改進。