Postgresql 中EFFECTIVE_CACHE_SIZE指的是什么，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

創(chuàng)新互聯(lián)企業(yè)建站,十余年網(wǎng)站建設(shè)經(jīng)驗(yàn)，專注于網(wǎng)站建設(shè)技術(shù)，精于網(wǎng)頁(yè)設(shè)計(jì)，有多年建站和網(wǎng)站代運(yùn)營(yíng)經(jīng)驗(yàn)，設(shè)計(jì)師為客戶打造網(wǎng)絡(luò)企業(yè)風(fēng)格，提供周到的建站售前咨詢和貼心的售后服務(wù)。對(duì)于成都網(wǎng)站制作、成都網(wǎng)站設(shè)計(jì)中不同領(lǐng)域進(jìn)行深入了解和探索，創(chuàng)新互聯(lián)在網(wǎng)站建設(shè)中充分了解客戶行業(yè)的需求，以靈動(dòng)的思維在網(wǎng)頁(yè)中充分展現(xiàn)，通過(guò)對(duì)客戶行業(yè)精準(zhǔn)市場(chǎng)調(diào)研，為客戶提供的解決方案。

有時(shí)候一本書(shū)不是每一章或者每一部分都寫的讓你覺(jué)得可以仔細(xì)的閱讀后能得到什么, 本期出于這個(gè)狀態(tài), 書(shū)中的第一句中提到 effecitve cache size  應(yīng)該進(jìn)行評(píng)估,評(píng)估的標(biāo)準(zhǔn)系統(tǒng)的系統(tǒng)的內(nèi)存怎么能滿足操作系統(tǒng)中磁盤的caching 和 當(dāng)數(shù)據(jù)庫(kù)在正常運(yùn)作后的內(nèi)存的使用. 整體來(lái)說(shuō)對(duì)于postgres來(lái)說(shuō)這個(gè)值在50% - 70% 與之有關(guān)的設(shè)置例如 random_page_cost 的值,會(huì)影響index scan 或 sequential scans 在數(shù)據(jù)查找中的到底更偏向于那個(gè).默認(rèn)是4.0 在使用 san/nas 技術(shù)可以將其調(diào)整為3 SSD的使用可以將其調(diào)整為1.5 到2.5.  

實(shí)際上在讀完這段,粗體部分個(gè)人能力,我沒(méi)有太明白他要表達(dá)什么.

所以下面的文字,是針對(duì)上面粗體的擴(kuò)展

舉一個(gè)例子, 例如我們有100G的內(nèi)存,我們到底能有多少的EFFECTIVE_CACHE_SIZE, 我們有2G 供給應(yīng)用系統(tǒng), 3GB 給postgresql來(lái)運(yùn)行自己的processes, 剩下的, 就是供給postgresql 的shared buffers 和FILESYSTEM CACHE

Share buffers 和 filesystem cache 主要的作用就是緩存數(shù)據(jù), 通過(guò)緩存數(shù)據(jù)來(lái)滿足數(shù)據(jù)處理時(shí),具體的信息一定在內(nèi)存中存在.

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

這些都是本期要弄一個(gè)清楚的問(wèn)題. 

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

有效能承載這些數(shù)據(jù),讓查詢優(yōu)化器能識(shí)別這些,更有效的利用這些內(nèi)存, 在源代碼中有一段注釋

實(shí)際上Postgresql 的內(nèi)存也和其他數(shù)據(jù)庫(kù)分為兩塊, 這里PG 內(nèi)存主要由 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)保存所有事務(wù)的狀態(tài)，是并發(fā)控制機(jī)制的一部分。提交日志被分配給共享內(nèi)存，并在整個(gè)事務(wù)處理過(guò)程中使用。

到此,上面的兩個(gè)問(wèn)題就很清晰了

1 share buffer 的分配很重要, 他提供了數(shù)據(jù)庫(kù)服務(wù)中到底有多少數(shù)據(jù)庫(kù)可以hit  buffer , 這嚴(yán)重影響數(shù)據(jù)庫(kù)對(duì)外服務(wù)的性能和質(zhì)量.

2 work_mem 的分配, 一個(gè)連接將使用一個(gè)work_mem 來(lái)進(jìn)行數(shù)據(jù)的處理,連接數(shù) * work_mem 就是你的local memory area 中的使用 內(nèi)存的大頭.

例如

我們支持500個(gè)連接, 每個(gè)連接最大使用 4MB的work_mem 則 500* 4MB ,將近會(huì)有2000MB在這一項(xiàng)中被使用.

所以這就引出另外的一些問(wèn)題, 如果索引數(shù)據(jù)會(huì)駐留在 share buffer中, 則使用什么樣的 index type 更有利于查詢,并節(jié)省內(nèi)存, 這在POSTGERSQL 中是可以探討的, 因?yàn)镻G支持的索引的TYPE 多,并且部分類型在部分應(yīng)用場(chǎng)景中索引可以變得很小,這一定是有利于系統(tǒng)的性能的和節(jié)省內(nèi)存.  

另一個(gè)部分就是 work_mem的設(shè)置, work_mem給的較大,則會(huì)在連接數(shù)較大的時(shí)候,浪費(fèi)過(guò)多的內(nèi)存, 而設(shè)置的過(guò)小,則也會(huì)影響系統(tǒng)查詢的性能. 這也是一個(gè)見(jiàn)仁見(jiàn)智的問(wèn)題, 例如你的系統(tǒng)是 OLAP OR  OLTP , 則在這個(gè)這個(gè)設(shè)置上也會(huì)有不同的做法.

這里對(duì)于pg初始時(shí)有一個(gè)壓測(cè)工具,便于對(duì)你當(dāng)前的postgresql 的系統(tǒng)性能進(jìn)行一個(gè)初步的理解.

關(guān)于Postgresql 中EFFECTIVE_CACHE_SIZE指的是什么問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。