適用於多處理應用程序的最佳PostgreSQL隔離級別

我有一個應用程序可以使多個進程自動從多個PostgreSQL表中讀取大量數據來進行數字運算，然後將結果存儲在單獨的表中。當我測試這只是一個進程，它是快速發展，並使用幾乎100％的CPU，但當我嘗試使用8核心機器上的8個進程，所有進程註冊約1％的CPU和整個任務似乎需要更長的時間。適用於多處理應用程序的最佳PostgreSQL隔離級別

當我檢查pg_stat_activity時，我看到幾個連接列爲「<IDLE> in transaction」。在提供了一些建議here後，我看了一下pg_locks，並且在幾十個只讀表中看到了數百個「AccessShareLock」鎖。基於docs，我相信這是默認設置，但我認爲這會導致進程彼此踩在一起，否定了多進程的好處。

是否有更高效的隔離級別使用，或者更好的方式來調整PostgreSQL以允許更快的只讀訪問幾個進程，所以每個都不需要鎖定表？具體來說，我使用Django作爲我的ORM。

來源

2014-02-20 Cerin

更好地使用另一種存儲。 Postgres針對事務性系統進行了優化，這可能與問題域相反。 HDF如何？ –

當你說「只讀表」時，你是說這些表只讀到你的應用程序，或者它們是隻讀到*所有*應用程序？ –

很難說出什麼是瓶頸，但AccessShareLock肯定不是。「閒置交易」表明瓶頸在您的應用程序中，而不是在數據庫中。頂部的頂級流程是什麼？他們在等待嗎？ – jjanes

不知道什麼是多核心節流，但它與隔離級別無關。即使你有併發的寫操作。 Per documentation:

利用併發控制MVCC模型而不是鎖定的主要優點是在MVCC收購查詢（讀）數據不寫入數據，獲取的鎖衝突等讀鎖永遠不會阻止寫作和寫作永不阻止閱讀。即使在通過使用創新的可串行化快照隔離（SSI）級別提供最嚴格的事務隔離級別時，PostgreSQL仍能保證這一保證。

大膽重視我的。

當然，閱讀也永遠不會阻止閱讀。

也許你需要在服務器上重新配置resource allocation？默認配置經常保守。另一方面，在多用戶環境中，一些參數不應設置得太高。想起了work_mem。檢查名單Performance Optimization in the Postgres Wiki。

最後：

Django的是我的ORM。

ORM經常嘗試保持平臺無關性並且無法充分發揮特定RDBMS的潛力。他們是原始的柺杖，並且在性能優化方面表現不佳。

來源

2014-02-20 01:54:23

一般公平點，但我不同意最後一個。 Django的ORM不過是原始的或者是柺杖。 – Cerin

適用於多處理應用程序的最佳PostgreSQL隔離級別

回答

相關問題