PG中需要給共享內(nèi)存分配多少內(nèi)存?為什么?
綜合指南:postgresql shared buffers
本文主要針對(duì)下面問(wèn)題詳述PG的共享內(nèi)存:PG中需要給共享內(nèi)存分配多少內(nèi)存?為什么?
非常奇怪,為什么我的RDS PG需要使用系統(tǒng)RAM的25%,而Aurora的PG卻需要分配75%?
理解PG中的共享內(nèi)存及操作系統(tǒng)的緩存
首先提出個(gè)問(wèn)題:PG中的bgwriter進(jìn)程是干什么的?
如果回答是將臟頁(yè)刷到磁盤(pán)的,那這就錯(cuò)了。他僅僅將臟頁(yè)刷寫(xiě)到操作系統(tǒng)的緩存,然后由操作系統(tǒng)調(diào)用sync將操作系統(tǒng)緩存刷寫(xiě)到磁盤(pán)。有點(diǎn)迷惑?那么接著我們說(shuō)道說(shuō)道。
由于PG輕量的特性,他高度依賴(lài)操作系統(tǒng)緩存,通過(guò)操作系統(tǒng)感知文件系統(tǒng)、磁盤(pán)布局以及讀寫(xiě)數(shù)據(jù)文件。下圖幫助了解數(shù)據(jù)如何在磁盤(pán)和共享緩存之間流動(dòng)。

因此當(dāng)發(fā)起“select *from emp”時(shí),數(shù)據(jù)會(huì)加載到操作系統(tǒng)緩存然后才到shared buffer。同樣當(dāng)將臟頁(yè)向磁盤(pán)刷寫(xiě)時(shí),也是先到操作系統(tǒng)緩存,然后由操作系統(tǒng)調(diào)用fsync()將操作系統(tǒng)緩存中數(shù)據(jù)持久化到磁盤(pán)。這樣PG實(shí)際上由兩份數(shù)據(jù),看起來(lái)有些浪費(fèi)空間,但是操作系統(tǒng)緩存是一個(gè)簡(jiǎn)單的LRU而不是數(shù)據(jù)庫(kù)優(yōu)化的clock sweep algorithm。一旦在shared_buffers中命中,那么讀就不會(huì)下沉到操作系統(tǒng)緩存。如果shared buffer和操作系統(tǒng)緩存有相同頁(yè),操作系統(tǒng)緩存中的頁(yè)很快會(huì)被驅(qū)逐替換。
我能影響操作系統(tǒng)的fsync將臟頁(yè)刷回磁盤(pán)嗎?
當(dāng)然,通過(guò)postgresql.conf中參數(shù)bgwriter_flush_after,該參數(shù)整型,默認(rèn)512KB。當(dāng)后臺(tái)寫(xiě)進(jìn)程寫(xiě)了這么多數(shù)據(jù)時(shí),會(huì)強(qiáng)制OS發(fā)起sync將cache中數(shù)據(jù)刷到底層存儲(chǔ)。這樣會(huì)限制內(nèi)核頁(yè)緩存中的臟數(shù)據(jù)數(shù)量,從而減小checkpoint時(shí)間或者后臺(tái)大批量寫(xiě)回?cái)?shù)據(jù)的時(shí)間。
不僅僅時(shí)bgwriter,即使checkpoint進(jìn)程和用戶(hù)進(jìn)程也從shared buffer刷寫(xiě)臟頁(yè)到OS cache。可以通過(guò)checkpoint_flush_after影響checkpoint進(jìn)程的fsync,通過(guò)backend_flush_after影響后臺(tái)進(jìn)程的fsync。
如果給OS cache很小值會(huì)怎么樣?
正如上文所述,一旦頁(yè)被標(biāo)記為臟,他就會(huì)刷寫(xiě)到操作系統(tǒng)緩存。操作系統(tǒng)可以更加自由地根據(jù)傳入的流量進(jìn)行IO調(diào)度。如果OS cache太小,則無(wú)法重新對(duì)write進(jìn)行排序從而優(yōu)化IO。這對(duì)于寫(xiě)操作頻繁的工作負(fù)載尤為重要,所以操作系統(tǒng)緩存大學(xué)也很重要。
如果給shared buffer很小值會(huì)怎么樣?
數(shù)據(jù)庫(kù)操作都在shared buffer,所以最好為shared buffer分配足夠空間。
建議值多大?
PG推薦系統(tǒng)內(nèi)存的25%給shared buffer,當(dāng)然可以根據(jù)環(huán)境進(jìn)行調(diào)整。
如果查看shared buffer中內(nèi)容?
PG的buffer cache擴(kuò)展可以幫助實(shí)時(shí)查看shared buffer中內(nèi)容。從shared_buffers中采集信息保存到pg_buffercache表中:
create extension pg_buffercache;
安裝好后,執(zhí)行下面查詢(xún)查看內(nèi)容:
SELECT c.relname
, pg_size_pretty(count(*) * 8192) as buffered
, round(100.0 * count(*) / ( SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer,1) AS buffers_percent
, round(100.0 * count(*) * 8192 / pg_relation_size(c.oid),1) AS percent_of_relation
FROM pg_class c
INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode
INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database())
WHERE pg_relation_size(c.oid) > 0
GROUP BY c.oid, c.relname
ORDER BY 3 DESC
LIMIT 10;
輸出:
postgres=# SELECT c.relname postgres-# , pg_size_pretty(count(*) * 8192) as buffered postgres-# , round(100.0 * count(*) / ( SELECT setting FROM pg_settings WHERE name='shared_buffers')::integer,1) AS buffers_percent postgres-# , round(100.0 * count(*) * 8192 / pg_relation_size(c.oid),1) AS percent_of_relation postgres-# FROM pg_class c postgres-# INNER JOIN pg_buffercache b ON b.relfilenode = c.relfilenode postgres-# INNER JOIN pg_database d ON (b.reldatabase = d.oid AND d.datname = current_database()) postgres-# WHERE pg_relation_size(c.oid) > 0 postgres-# GROUP BY c.oid, c.relname postgres-# ORDER BY 3 DESC postgres-# LIMIT 10; relname | buffered | buffers_percent | percent_of_relation ---------------------------+------------+-----------------+--------------------- pg_operator | 80 kB | 0.1 | 71.4 pg_depend_reference_index | 96 kB | 0.1 | 27.9 pg_am | 8192 bytes | 0.0 | 100.0 pg_amproc | 24 kB | 0.0 | 100.0 pg_cast | 8192 bytes | 0.0 | 50.0 pg_depend | 64 kB | 0.0 | 14.0 pg_index | 32 kB | 0.0 | 100.0 pg_description | 40 kB | 0.0 | 14.3 pg_language | 8192 bytes | 0.0 | 100.0 pg_amop | 40 kB | 0.0 | 83.3 (10 rows)
如何感知數(shù)據(jù)到達(dá)操作系統(tǒng)緩存層?
需要安裝包pgfincore:
As root user: export PATH=/usr/local/pgsql/bin:$PATH //Set the path to point pg_config. tar -xvf pgfincore-v1.1.1.tar.gz cd pgfincore-1.1.1 make clean make make install Now connect to PG and run below command postgres=# CREATE EXTENSION pgfincore;
執(zhí)行下面命令:
select c.relname,pg_size_pretty(count(*) * 8192) as pg_buffered,
round(100.0 * count(*) /
(select setting
from pg_settings
where name='shared_buffers')::integer,1)
as pgbuffer_percent,
round(100.0*count(*)*8192 / pg_table_size(c.oid),1) as percent_of_relation,
( select round( sum(pages_mem) * 4 /1024,0 )
from pgfincore(c.relname::text) )
as os_cache_M(jìn)B ,
round(100 * (
select sum(pages_mem)*4096
from pgfincore(c.relname::text) )/ pg_table_size(c.oid),1)
as os_cache_percent_of_relation,
pg_size_pretty(pg_table_size(c.oid)) as rel_size
from pg_class c
inner join pg_buffercache b on b.relfilenode=c.relfilenode
inner join pg_database d on (b.reldatabase=d.oid and d.datname=current_database()
and c.relnamespace=(select oid from pg_namespace where nspname='public'))
group by c.oid,c.relname
order by 3 desc limit 30;
輸出:
relname |pg_buffered|pgbuffer_per|per_of_relation|os_cache_mb|os_cache_per_of_relation|rel_size
---------+-----------+------------+---------------+-----------+------------------------+--------
emp | 4091 MB | 99.9 | 49.3 | 7643 | 92.1 | 8301 MB
pg_buffered表示PG buffer cache中有多少數(shù)據(jù),pgbuffer_percent表示pg_buffered/total_buffer_size*100。os_cache_mb表示OS cache中緩存多少。我們的表emp有8301MB數(shù)據(jù),92%數(shù)據(jù)在OS cache,49.3%在shared buffers,大約50%的數(shù)據(jù)是冗余的。
為什么Aurora PG推薦75%的內(nèi)存給shared buffer?
Aurora不使用文件系統(tǒng)緩存,因此可以提升shared_buffers大小以提升性能。最佳實(shí)踐值為75%。Work_mem、maintenance_work_mem和其他本地內(nèi)存不是shared buffer的一部分。如果應(yīng)用請(qǐng)求大量客戶(hù)端連接,或需要大量work_mem時(shí),需要將這個(gè)值調(diào)小。
發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
圖片新聞
-

落地?zé)o錫!京東首個(gè)物流機(jī)器人超級(jí)工廠來(lái)了
-

OpenAI發(fā)布的AI瀏覽器,市場(chǎng)為何反應(yīng)強(qiáng)烈?
-

馬云重返一線督戰(zhàn),阿里重啟創(chuàng)始人模式
-

機(jī)器人奧運(yùn)會(huì)戰(zhàn)報(bào):宇樹(shù)機(jī)器人摘下首金,天工Ultra搶走首位“百米飛人”
-

存儲(chǔ)圈掐架!江波龍起訴佰維,索賠121萬(wàn)
-

長(zhǎng)安汽車(chē)母公司突然更名:從“中國(guó)長(zhǎng)安”到“辰致科技”
-

豆包前負(fù)責(zé)人喬木出軌BP后續(xù):均被辭退
-

字節(jié)AI Lab負(fù)責(zé)人李航卸任后返聘,Seed進(jìn)入調(diào)整期
最新活動(dòng)更多
-
即日-5.20立即下載>> 【限時(shí)免費(fèi)】物理場(chǎng)仿真助力生物醫(yī)學(xué)領(lǐng)域技術(shù)創(chuàng)新
-
精彩回顧立即查看>> 【直播】 智測(cè)未來(lái)·2026海克斯康春季產(chǎn)品創(chuàng)新日
-
精彩回顧立即查看>> 【線下論壇】新唐科技×芯唐南京 2026 年度研討會(huì)
-
精彩回顧立即查看>> OFweek 2026(第十五屆)中國(guó)機(jī)器人產(chǎn)業(yè)大會(huì)
-
精彩回顧立即查看>> 維科杯· OFweek 2025中國(guó)機(jī)器人行業(yè)年度評(píng)選
-
精彩回顧立即查看>> 【在線會(huì)議】液冷服務(wù)器信號(hào)完整性及冷卻液關(guān)鍵電參數(shù)測(cè)試
推薦專(zhuān)題
- 1 特斯拉Optimus Gen3量產(chǎn)在即,哪些環(huán)節(jié)最具確定性?
- 2 OpenAI深夜王炸!ChatGPT Images 2.0實(shí)測(cè):中文穩(wěn)、細(xì)節(jié)炸,設(shè)計(jì)師慌了
- 3 AI狂歡遇上油價(jià)破百,全球股市還能漲多久? | 產(chǎn)聯(lián)看全球
- 4 6000億美元估值錨定:字節(jié)跳動(dòng)的“去單一化”突圍與估值重構(gòu)
- 5 Tesla AI5芯片最新進(jìn)展總結(jié)
- 6 連夜測(cè)了一波DeepSeek-V4,我發(fā)現(xiàn)它可能只剩“審美”這個(gè)短板了
- 7 熱點(diǎn)丨AI“瑜亮之爭(zhēng)”:既生OpenClaw,何生Hermes?
- 8 2026,人形機(jī)器人只贏了面子
- 9 AI界的殺豬盤(pán):9秒刪庫(kù)跑路,全員被封號(hào),還繼續(xù)扣錢(qián)!
- 10 AI Infra產(chǎn)業(yè)鏈卡在哪里了?
- 高級(jí)軟件工程師 廣東省/深圳市
- 自動(dòng)化高級(jí)工程師 廣東省/深圳市
- 光器件研發(fā)工程師 福建省/福州市
- 銷(xiāo)售總監(jiān)(光器件) 北京市/海淀區(qū)
- 激光器高級(jí)銷(xiāo)售經(jīng)理 上海市/虹口區(qū)
- 光器件物理工程師 北京市/海淀區(qū)
- 激光研發(fā)工程師 北京市/昌平區(qū)
- 技術(shù)專(zhuān)家 廣東省/江門(mén)市
- 封裝工程師 北京市/海淀區(qū)
- 結(jié)構(gòu)工程師 廣東省/深圳市


分享





