在學(xué)習(xí)PostgreSQL的過程中，很容易陷入一種情況，貌似都懂，一問就含糊，今天我就來捋一捋那團亂麻。

postgresql 啟動源于守護進程，其功能強大，主管比如執(zhí)行恢復(fù)、初始化共享數(shù)據(jù)結(jié)構(gòu)/內(nèi)存空間，以及啟動強制和可選的進程。

PostgreSql 在啟動后，就開始接受客戶的訪問，下圖演示了一個客戶如何申請連接，由守護進程來分配一個子進程，然后來服務(wù)于客戶的方式。

當(dāng)有成千上萬的用戶要讀取數(shù)據(jù)庫中的數(shù)據(jù)，并且想更高速度度的讀取，那就會牽扯到PG中的內(nèi)存系統(tǒng)，PG的內(nèi)存系統(tǒng)中，客戶與backend process來進行交互，而backend process 會與PG的共享buffer中，而與其他數(shù)據(jù)庫不同的地方是，PG的內(nèi)存并不會和其他的三家的數(shù)據(jù)庫一樣，他要求的本身的buffer 的設(shè)置不會特別大(相對于其他三家的)，他的設(shè)計中還要利用LINUX 系統(tǒng)的緩沖系統(tǒng)，在數(shù)據(jù)的讀取上并不會引起任何問題，速度上也會有保障。

除了這兩種級別的緩存之外，我們還可以使用磁盤控制器緩存、磁盤驅(qū)動器緩存等等。

上面基本上在關(guān)注與數(shù)據(jù)庫的讀操作，關(guān)于寫操作中的一個問題就是大量數(shù)據(jù)的更改插入，數(shù)據(jù)是否馬上會進行刷盤用戶對表數(shù)據(jù)進行大量更改并發(fā)提交的情況下，不會馬上對底層數(shù)據(jù)文件執(zhí)行寫操作。這可能只會導(dǎo)致確保提前寫日志(WAL)文件與WAL緩沖區(qū)保持同步。那怎么來保證事務(wù)的持久性的問題和事務(wù)的原子性的問題，WAL 日志的重要的作用就是，保證系統(tǒng)的高性能下的AD功能，并讓數(shù)據(jù)最終一致在數(shù)據(jù)文件中。

通過 buffercache 和 oid2name 兩個命令可以看到目前的數(shù)據(jù)庫的buffer到底有那些數(shù)據(jù)庫已經(jīng)在內(nèi)存中。

當(dāng)然如果想關(guān)心一下，用戶表的buffer讀取的數(shù)據(jù)塊的浮動可以將上的查詢保存在一個表里面，并輔以時間，這樣你就可以繪制出一個用戶表的burfer的周期表。(能干什么自己想想，很有意思的)

SELECT  
c.relname,  
count(*) AS buffers  
FROM pg_class c  
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 c.relname NOT LIKE 'pg%' GROUP BY c.relname ORDER BY 2 DES 

然后我們就到了內(nèi)存與磁盤的交換，checkpoint，如

數(shù)據(jù)在內(nèi)存中也不能一直寄存，需要落盤，這就牽扯到下一步checkpoint，檢查點，檢查點是一個強制的過程，在PG中數(shù)據(jù)總是以數(shù)據(jù)塊寫入和讀取的，無論這個塊的數(shù)據(jù)是否占滿8K，讀取的時候也是以塊為單位進行讀取，

用戶在緩沖區(qū)中進行了更改，緩沖區(qū)與物理磁盤的數(shù)據(jù)文件不一致，該緩沖區(qū)的數(shù)據(jù)就是臟的，checkpoint的作用就是要將這些已經(jīng)確認(rèn)改變的數(shù)據(jù)寫入到數(shù)據(jù)的文件的過程。相關(guān)的所有的數(shù)據(jù)頁和索引頁都會進行更新，同時將這個頁面標(biāo)記OK。

這樣的方式可以讓HEAP PAGE 和 INDEX PAGE 在這個checkpoint之前的頁面都刷到磁盤的數(shù)據(jù)文件中。那么我可以理解的是，如果此時數(shù)據(jù)庫沒有任何的其他的手段，此時斷電，那CHECKPOINT 之后的數(shù)據(jù)就會丟失(實際情況當(dāng)然不會)，這也就是redo，重做日志要檢查checkpoint點的問題，他要確定從哪里開始重做

checkpoint 有三個參數(shù)，checkpoint_segments, checkpoint_timeout, 和checkpoint_completion_target.(PG 9X)

三個參數(shù)前兩個屬于湊夠多少wal 才開始 checkpoint, 如果這個長時間沒有checkpoint 那就根據(jù)第二個參數(shù) checkpint_timeout 來根據(jù)時間來進行checkpoint，當(dāng)然這樣做的后果是，如果某個階段數(shù)據(jù)量比較大，I/O就會出現(xiàn)消耗較高的情況，那第三個參數(shù)，checkpoint_completion_target就啟動作用，讓這個突發(fā)的情況，稍微的緩解，拉長這個寫入的時間，讓I/O系統(tǒng)不會那么的忙。

而當(dāng)前PG11 中的與checkpoint的有關(guān)的參數(shù)不在有checkpoint_segments，換來的是max_wal_size ，要不超過設(shè)定時間去checkpoint 要不就是超過 max-wal-size 來進行 checkpoint，感覺這樣設(shè)置比較合理，如果使用上面的方法，其實使用一個函數(shù)，就可以讓PG的checkpoint紊亂，甚至可能會宕機(使壞的方法是就算了)

最后要在wal log 里面結(jié)束此次的捋一捋的活動。當(dāng)我們對數(shù)據(jù)進行更改時，不會立即將更改寫入數(shù)據(jù)文件，對緩沖區(qū)中的塊進行更改，并將這些更改的記錄寫入WAL緩沖區(qū)，所以wal 才是保證系統(tǒng)運行效率與數(shù)據(jù)安全之間的一個妥協(xié)的產(chǎn)品。

select * from pg_walfile_name(pg_current_wal_lsn()); 

如何知道當(dāng)前你正在操作的那個 wal 日志。(PG11)

SELECT pg_xlogfile_name(pg_current_xlog_location()); (PG 9X) 

使用過PG的人都知道PG 沒有 DOUBLE WRITE 這個功能其實(DW是那個數(shù)據(jù)庫的特征就不在說了)，F(xiàn)ULL PAGE 來支持的，到底FULL PAGE 是用了什么方法，躲避了 DW ，保證了數(shù)據(jù)的完全。當(dāng)然這也是要消耗系統(tǒng)的I/O性能的，同時也可以通過細(xì)調(diào)某些參數(shù)來緩解某些性能問題。

在這之前我們說說為什么會有這樣的情況，數(shù)據(jù)頁如果是8KB的情況下，那硬件和系統(tǒng)能一次將這些信息都寫到磁盤， 答案當(dāng)然是 不 不 不

LINUX 一次是 4KB ，那硬件系統(tǒng)就更不知道是 4KB 還是 8KB ，所以如果系統(tǒng)CRASH 了，怎么辦你明明寫了8KB 人家寫了 4KB 就斷了，剩下了4KB 找誰，丟了，那啟動后，物理頁面損壞，誰給修，你給修。所以不同的數(shù)據(jù)庫就各顯神通，要把這塊給彌補了。

PG 這里就是 FULL PAGE 主要是操作的是將PostgreSQL服務(wù)器會在檢查點后第一次修改該頁時將每個磁盤頁的全部內(nèi)容寫入WAL。這樣的好處是如果在下一次checkpoint的之前幾期crash了，則我們在WAL 中有所有的數(shù)據(jù)頁面，通過這些數(shù)據(jù)頁面就可以將數(shù)據(jù)恢復(fù)。不好的地方就是將數(shù)據(jù)寫入到了WAL日志中，多寫數(shù)據(jù)是一定要影響性能的。

這里如果我們提高checkpoint的頻率，會從邏輯的角度來抵消FULL page的影響，而如果縮小checkpoint的頻率，那可能就會人為的創(chuàng)造出一個大的突發(fā)寫入，那上邊的一個參數(shù)就的調(diào)整了，那個參數(shù)呢，我想你已經(jīng)知道了。

但結(jié)果是我不會關(guān)閉FULL PAGE 因為性能與數(shù)據(jù)的安全性比較，那個應(yīng)該優(yōu)先，不言而喻。

以上內(nèi)容由東方瑞通資深講師 Austin供稿，13年專業(yè)DBA經(jīng)驗，曾任互聯(lián)網(wǎng)金融公司Senior DBA、500強制藥企業(yè)Senior DBA，精通Mysql、PostgreSQL、Mongo DB、SQLServer。