Postgresql 中EFFECTIVE_CACHE_SIZE指的是什么

Postgresql 中EFFECTIVE_CACHE_SIZE指的是什么，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

有時候一本書不是每一章或者每一部分都寫的讓你覺得可以仔細的閱讀后能得到什么, 本期出于這個狀態, 書中的第一句中提到 effecitve cache size  應該進行評估,評估的標準系統的系統的內存怎么能滿足操作系統中磁盤的caching 和 當數據庫在正常運作后的內存的使用. 整體來說對于postgres來說這個值在50% - 70% 與之有關的設置例如 random_page_cost 的值,會影響index scan 或 sequential scans 在數據查找中的到底更偏向于那個.默認是4.0 在使用 san/nas 技術可以將其調整為3 SSD的使用可以將其調整為1.5 到2.5.  

實際上在讀完這段,粗體部分個人能力,我沒有太明白他要表達什么.

所以下面的文字,是針對上面粗體的擴展

舉一個例子, 例如我們有100G的內存,我們到底能有多少的EFFECTIVE_CACHE_SIZE, 我們有2G 供給應用系統, 3GB 給postgresql來運行自己的processes, 剩下的, 就是供給postgresql 的shared buffers 和FILESYSTEM CACHE

Share buffers 和 filesystem cache 主要的作用就是緩存數據, 通過緩存數據來滿足數據處理時,具體的信息一定在內存中存在.

其實到這里有兩點是模糊的, 1 連接到POSTGRESQL的SESSION 是否需要內存, 2 數據的排序和臨時表等等的內存釋放包含在 effective_cache_size 也就是ORACLE 中的 SGA PGA的含義,在PG中是否有明確的區分.

這些都是本期要弄一個清楚的問題. 

另外要明確的是,effective_cache_size被設置的意義在哪里, 還是回到根本上,數據庫的性能,有效的配置和設置effective cache size 真正的意義是提高數據庫運行時的性能.

有效能承載這些數據,讓查詢優化器能識別這些,更有效的利用這些內存, 在源代碼中有一段注釋

實際上Postgresql 的內存也和其他數據庫分為兩塊, 這里PG 內存主要由 local memory area  和  shared buffer pool 組成,  shared buffer pool 其中就包括 share buffer wal buffer  commit log  幾部分, 而local memory area 主要由  work_mem maintenance work mem  , temp buffer 組成.

其中CLOG是提交日志(CLOG)保存所有事務的狀態，是并發控制機制的一部分。提交日志被分配給共享內存，并在整個事務處理過程中使用。

到此,上面的兩個問題就很清晰了

1 share buffer 的分配很重要, 他提供了數據庫服務中到底有多少數據庫可以hit  buffer , 這嚴重影響數據庫對外服務的性能和質量.

2 work_mem 的分配, 一個連接將使用一個work_mem 來進行數據的處理,連接數 * work_mem 就是你的local memory area 中的使用 內存的大頭.

例如

我們支持500個連接, 每個連接最大使用 4MB的work_mem 則 500* 4MB ,將近會有2000MB在這一項中被使用.

所以這就引出另外的一些問題, 如果索引數據會駐留在 share buffer中, 則使用什么樣的 index type 更有利于查詢,并節省內存, 這在POSTGERSQL 中是可以探討的, 因為PG支持的索引的TYPE 多,并且部分類型在部分應用場景中索引可以變得很小,這一定是有利于系統的性能的和節省內存.  

另一個部分就是 work_mem的設置, work_mem給的較大,則會在連接數較大的時候,浪費過多的內存, 而設置的過小,則也會影響系統查詢的性能. 這也是一個見仁見智的問題, 例如你的系統是 OLAP OR  OLTP , 則在這個這個設置上也會有不同的做法.

這里對于pg初始時有一個壓測工具,便于對你當前的postgresql 的系統性能進行一個初步的理解.

關于Postgresql 中EFFECTIVE_CACHE_SIZE指的是什么問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。