2013-07-17 23 views
2

我有一個64GB內存和PostgreSQL 9.2的服務器。它只有一個小型數據庫「A」,只有4GB,每小時只查詢一次,還有一個大型數據庫「B」,大約60GB,每秒查詢40-50x!PostgreSQL性能:當服務器忙於大數據庫時,很少在內存中使用小型數據庫

正如預期的那樣,Linux和PostgreSQL用較大的數據庫數據填充RAM,因爲它更常被訪問。

我現在的問題是,對小數據庫「A」的查詢是至關重要的,必須運行在< 500毫秒。日誌文件每天顯示幾個查詢,但花費> 3s。如果我手動執行它們,它們也只需要10ms,因此我的索引很好。

所以我猜想,當PostgreSQL必須從磁盤加載小型數據庫索引塊時,纔會發生這些長跑運動員。

我已經有了一種「緩存加熱器」腳本,它每秒都會重複「SELECT * FROM x ORDER BY y」查詢到小型數據庫,但它浪費了大量的CPU能力,僅僅改善了一點情況。

有沒有更多的想法如何告訴PostgreSQL我真的希望這個小型數據庫在內存中「粘」?

+0

如果您使用SQLite的內存中實例來保存4Gig數據庫會怎麼樣?仔細查看PostGresql的文檔,它看起來並不像它專門在內存中運行,除非在RAM磁盤上運行它。 –

+0

@RobertHarvey相當多; Pg目前不提供表格/索引固定。 –

+0

如果手工運行查詢只需要10ms,但您的緩存加熱器不能改善非手邊情況,那麼您的緩存加熱器會運行錯誤的查詢並加熱緩存的錯誤部分。爲什麼'order by'? – jjanes

回答

1

PostgreSQL不提供在內存中固定表格的方法,但社區當然會歡迎願意參與經過深思熟慮,經過測試和基準測試的提案,以便願意支持這些提案的人真實的代碼。

您現在用PostgreSQL的最佳選擇是爲響應時間關鍵數據庫運行單獨的PostgreSQL實例。給這個DB一個足夠大的shared_buffers,整個DB將駐留在shared_buffers

執行不是在虛擬硬盤或其他非持久存儲上創建表空間,並將需要很少但在那裏快速訪問的數據。所有的表空間必須是可訪問的,否則整個系統將停止;如果你丟失了一個表空間,那麼你實際上會丟失整個數據庫集羣。

+0

不幸的是,我不認爲有任何保證操作系統不會決定分頁出大部分空閒的服務器的shared_buffers。 – jjanes

+0

@jjanes好點,至少在9.3(?)+上使用POSIX shmem。我不確定sysv shmem是否可分頁。也許你需要一個'mlock()''shared_buffers'的擴展。 –