文章目錄
一、PostgreSQL進程分類
- 主進程Postmaster
- 輔助子進程Logger(系統日誌)進程
- 輔助子進程BgWriter(後臺寫)進程
- 輔助子進程WalWriter(預寫日誌)進程
- 輔助子進程PgArch(歸檔)進程
- 輔助子進程AutoVacuum(系統自動清理)進程
- 輔助子進程PgStat(統計信息收集)進程
- 輔助子進程CheckPoint(檢查點)進程
二、進程介紹
2.1 主進程postmaster
主進程postmaster是數據庫實例的總控進程，負責啓停數據庫,同時會fork出一些輔助子進程，這些輔助子進程各自負責一部分功能；postgres爲postmaster 的軟鏈接，pg_ctl就是封裝了postgres命令。
-rwxr-xr-x 1 postgres postgres 36M Sep 3 22:58 postgres
lrwxrwxrwx 1 postgres postgres 8 Sep 3 22:58 postmaster -> postgres
用戶連接時，會先與postmaster進程建立連接，進行身份校驗，之後fork出服務子進程。pg_stat_activity表中PID就爲這些連接進程的PID。
postgres=# select * from pg_stat_activity;
+-[ RECORD 1 ]-----+---------------------------------+
| datid | |
| datname | |
| pid | 27436 |
| usesysid | 10 |
| usename | postgres |
| application_name | |
| client_addr | |
| client_hostname | |
| client_port | |
| backend_start | 2020-12-20 11:38:11.58027+08 |
| xact_start | |
| query_start | |
| state_change | |
| wait_event_type | Activity |
| wait_event | LogicalLauncherMain |
| state | |
| backend_xid | |
| backend_xmin | |
| query | |
| backend_type | logical replication launcher |
2.2 Logger系統日誌進程
Logger系統日誌進程通過postmaster進程、服務進程和其餘輔助進程收集所有的stderr輸出，並記錄到日誌文件中。相關參數如下：
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%a.log'
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 0
#log_destination：配置日誌輸出目標，根據不同的運行平臺會設置不同的值，Linux下默認爲stderr。
#logging_collector：是否開啓日誌收集器，當設置爲on時啓動日誌功能；否則，系統將不產生系統日誌輔助進程。
#log_directory：配置日誌輸出文件夾。
#log_filename：配置日誌文件名稱命名規則。
#log_rotation_size：配置日誌文件大小，當前日誌文件達到這個大小時會被關閉，然後創建一個新的文件來作爲當前日誌文件。
2.3 BgWriter後臺寫進程
BgWriter進程負責把共享內存中的髒頁寫到磁盤上。爲了提高性能，我們可能並不需要每次進行持久化，如果刷新頻率過快會導致頻繁的IO，如果刷新頻率過慢會導致新查詢缺少內存空間；因此PostgreSQL通過以下SQL進行管理：
bgwriter_delay = 200ms # 10-10000ms between rounds
bgwriter_lru_maxpages = 100 # max buffers written/round, 0 disables
bgwriter_lru_multiplier = 2.0 # 0-10.0 multiplier on buffers scanned/round
bgwriter_flush_after = 1024kB # measured in pages, 0 disables
#bgwriter_delay:backgroud writer進程連續兩次flush數據之間的時間的間隔。默認值是200，單位是毫秒。
#bgwriter_lru_maxpages：backgroud writer進程每次寫的最多數據量，默認值是100，單位buffers。如果髒數據量小於該數值時，寫操作全部由backgroud writer進程完成；反之，大於該值時，大於的部分將有server process進程完成。設置該值爲0時表示禁用backgroud writer寫進程，完全有server process來完成；配置爲-1時表示所有髒數據都由backgroud writer來完成。(這裏不包括checkpoint操作)
#bgwriter_lru_multiplier：這個參數表示每次往磁盤寫數據塊的數量，當然該值必須小於bgwriter_lru_maxpages。設置太小時需要寫入的髒數據量大於每次寫入的數據量，這樣剩餘需要寫入磁盤的工作需要server process進程來完成，將會降低性能；值配置太大說明寫入的髒數據量多於當時所需buffer的數量，方便了後面再次申請buffer工作，同時可能出現IO的浪費。該參數的默認值是2.0。
bgwriter的最大數據量計算方式：
1000/bgwriter_delay*bgwriter_lru_maxpages*8K=最大數據量
#bgwriter_flush_after：數據頁大小達到bgwriter_flush_after時觸發BgWriter，默認是512KB。
2.4 WalWriter預寫日誌進程
預寫日誌可以保證數據的完整性；在修改數據之前，數據庫會將修改操作記錄到磁盤中。這樣就不必擔心數據未持久化到磁盤導致數據丟失。如果數據庫宕機，重啓後數據庫會讀取WAL日誌最後一部分重新執行，將數據庫恢復爲宕機時的狀態。WAL日誌保存在pg_xlog下，xlog文件的默認大小爲16MB，在xlog目錄下會保存多個日誌，來保證未持久化的數據可以恢復，不需要的日誌會自動被覆蓋。相關參數如下：
#wal_level = minimal # minimal, replica, orlogical
# (changerequires restart)
#fsync = on # flush data to disk for crash safety
# (turningthis off can cause
# unrecoverable datacorruption)
#synchronous_commit =on # synchronization level;
# off, local,remote_write, remote_apply
,or on
#wal_sync_method =fsync # the default is thefirst option
# supported by theoperating system:
# open_datasync
# fdatasync (default on Linux)
# fsync
# fsync_writethrough
# open_sync
full_page_writes =on # recover from partial page writes
#wal_compression =off # enable compression of full-pagewrites
#wal_log_hints =off # also do full pagewrites of non-critical updates
#wal_buffers = -1 # min 32kB, -1 sets basedon shared_buffers
#wal_writer_delay = 200ms # 1-10000 milliseconds
#wal_writer_flush_after= 1MB # 0 disables
#commit_delay = 0 # range 0-100000, inmicroseconds
#commit_siblings =5 # range 1-1000
# - Checkpoints -
#checkpoint_timeout =5min # range 30s-1d
#max_wal_size = 1GB
#min_wal_size = 80MB
#checkpoint_completion_target= 0.5 # checkpoint target duration,0.0 - 1.0
#checkpoint_flush_after= 0 # 0 disables #default is 256kB on linux, 0 otherwise
#checkpoint_warning =30s # 0 disables
wal_level：控制wal存儲的級別。wal_level決定有多少信息被寫入到WAL中。默認值是最小的（minimal），其中只寫入從崩潰或立即關機中恢復的所需信息。replica 增加 wal 歸檔信息同時包括只讀服務器需要的信息。（9.6 中新增，將之前版本的 archive 和 hot_standby合併）
fsync:該參數直接控制日誌是否先寫入磁盤。默認值是ON(先寫入)。開啓該值時表明，更新數據寫入磁盤時系統必須等待WAL的寫入完成。可以配置該參數爲OFF，更新數據寫入磁盤完全不用等待WAL的寫入完成，沒有了等待的時間，顯然接下來的工作能夠更早的去做，節省了時間，提高了性能。其直接隱患是無法保證在系統崩潰時最近的事務能夠得到恢復，也就無法保證相關數據的真實與正確性。
synchronous_commit:該參數表明是否等待WAL完成後才返回給用戶事務的狀態信息。默認值是ON，表明必須等待WAL完成後才返回事務狀態信息。配置OFF值能夠更快的反饋回事務狀態。因參數只是控制事務的狀態反饋，因此對於數據的一致性不存在風險。但事務的狀態信息影響着數據庫的整個狀態。該參數可以靈活的配置，對於業務沒有嚴謹要求的事務可以配置爲OFF，能夠爲系統的性能帶來不小的提升。
wal_sync_method:WAL 寫入磁盤的控制方式，默認值是fsync。可選用值：open_datasync，fdatasync，fsync_writethrough，fsync,open_sync。一般採用默認值即可，對於裸設備或文件系統的可選配置，在實際的使用中所帶來的方便相對fsync很有限。
full_page_writes:參數表明是否將整個page寫入WAL。postgresql中數據處理過程中的數據只保存在內存和WAL中，在內存中的整個page中包含更新提交和沒有提交的，如果不將整個page寫入WAL中，在介質恢復的時候WAL中記錄的數據不足以實現完整的恢復(說白了就是無法實現介質恢復時事務的回滾)。
wal_buffers:用於存放WAL數據的內存空間，最小32K。
wal_writer_delay： WAL writer進程的間歇時間。默認值是200ms。準確的配置應該根據自身系統的運行狀況。如果時間過長可能造成WAL buffer的內存不足；反之過小將會引起WAL的不斷的寫入，對磁盤的IO也是很大考驗。
wal_writer_flush_after wal write的字節數超過配置的閾值(wal_writer_flush_after)時,觸發fsync，默認值爲1MB，如果設置爲0，關閉該特性（9.6版本新增的參數）
commit_delay:表示一個已經提交的數據在WAL buffer中存放的時間，單位ms，默認值是0，不用延遲。非0值表示可能存在多個事務的WAL同時寫入磁盤。如果設置爲非0，表明了某個事務執行 commit後不會立即寫入WAL中，而仍存放在WAL buffer中，這樣對於後面的事務申請WAL buffer時非常不利，尤其是提交事務較多的高峯期，可能引起WAL buffer內存不足。如果內存足夠大，可以儘量延長該參數值，能夠使數據集中寫入這樣降低了系統的IO，提高了性能。同樣如果此時崩潰數據面臨着丟失的危險。
commit_siblings該參數還決定了commit_delay的有效性。系統默認值是5。表示當一個事務發出提交請求，此時數據庫中正在執行的事務數量大於5，則該事務將等待一段時間(commit_delay的值)，反之，該事務則直接寫入WAL。
min_wal_size ：最小的wal 空間
2.5 PgArch歸檔進程
WAL日誌被循環使用，老的日誌會被覆蓋；PgArch進程會在日誌被覆蓋前備份出來。結合全備數據加上之後的WAL日誌即可把數據庫前滾到全量後的任意時間點。相關參數：
archive_mode = on # enables archiving; off, on, or always
#archive_command = '' # command to use to archive a logfile segment
# placeholders: %p = path of file to archive
# e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
#archive_timeout = 0 # force a logfile segment switch after this
#archive_mode：表示是否進行歸檔操作，可選擇爲off（關閉）、on（啓動）和always（總是開啓），默認值爲off（關閉）。
#archive_command：由管理員設置的用於歸檔WAL日誌的命令。在用於歸檔的命令中，預定義變量“%p”用來指代需要歸檔的WAL全路徑文件名，“%f”表示不帶路徑的文件名（這裏的路徑都是相對於當前工作目錄的路徑）。每個WAL段文件歸檔時將調用archive_command所指定的命令。當歸檔命令返回0時，PostgreSQL就會認爲文件被成功歸檔，然後就會刪除或循環使用該WAL段文件。否則，如果返回一個非零值，PostgreSQL會認爲文件沒有被成功歸檔，便會週期性地重試直到成功。
#archive_timeout：表示歸檔週期，在超過該參數設定的時間時強制切換WAL段，默認值爲0（表示禁用該功能）。
2.6 AutoVacuum自動清理進程
在PostgreSQL中，對數據進行UPDATE或者DELETE操作後，數據庫不會立即刪除舊版本的數據，而是標記爲刪除狀態。當事務提交後，舊版本的數據已經沒有價值了，數據庫需要清理垃圾數據騰出空間，而清理工作就是AutoVacuum進程進行的。相關參數如下：
#autovacuum_work_mem = -1 # min 1MB, or -1 to use maintenance_work_mem
#autovacuum = on # Enable autovacuum subprocess? 'on'
#log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
#autovacuum_max_workers = 3 # max number of autovacuum subprocesses
#autovacuum_naptime = 1min # time between autovacuum runs
#autovacuum_vacuum_threshold = 50 # min number of row updates before
#autovacuum_analyze_threshold = 50 # min number of row updates before
#autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
#autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
#autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
#autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age
#autovacuum_vacuum_cost_delay = 2ms # default vacuum cost delay for
# autovacuum, in milliseconds;
#autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
# autovacuum, -1 means use
#autovacuum：是否啓動系統自動清理功能，默認值爲on。
#log_autovacuum_min_duration：這個參數用來記錄 autovacuum 的執行時間，當 autovaccum 的執行時間超過 log_autovacuum_min_duration參數設置時，則autovacuum信息記錄到日誌裏，默認爲 "-1", 表示不記錄。
#autovacuum_max_workers：設置系統自動清理工作進程的最大數量。
#autovacuum_naptime：設置兩次系統自動清理操作之間的間隔時間。
#autovacuum_vacuum_threshold和autovacuum_analyze_threshold：設置當表上被更新的元組數的閾值超過這些閾值時分別需要執行vacuum和analyze。
#autovacuum_vacuum_scale_factor和autovacuum_analyze_scale_factor：設置表大小的縮放係數。
#autovacuum_freeze_max_age：設置需要強制對數據庫進行清理的XID上限值。
#autovacuum_vacuum_cost_delay：當autovacuum進程即將執行時，對 vacuum 執行 cost 進行評估，如果超過 autovacuum_vacuum_cost_limit設置值時，則延遲，這個延遲的時間即爲 autovacuum_vacuum_cost_delay。如果值爲 -1, 表示使用autovacuum_vacuum_cost_delay 值，默認值爲 20 ms。
#autovacuum_vacuum_cost_limit：這個值爲 autovacuum 進程的評估閥值, 默認爲 -1, 表示使用 "vacuum_cost_limit " 值，如果在執行autovacuum 進程期間評估的cost 超過 autovacuum_vacuum_cost_limit, 則 autovacuum 進程則會休眠。
2.7 PgStat統計數據收集進程
PgStat進程是PostgreSQL數據庫的統計信息收集器，用來收集數據庫運行期間的統計信息，如表的增刪改次數，數據塊的個數，索引的變化等等。收集統計信息主要是爲了讓優化器做出正確的判斷，選擇最佳的執行計劃。如下
#track_commit_timestamp = off # collect timestamp of transaction commit
#track_activities = on
#track_counts = on
#track_io_timing = off
#track_functions = none # none, pl, all
#track_activity_query_size = 1024 # (change requires restart)
# requires track_counts to also be on.
#track_activities：表示是否對會話中當前執行的命令開啓統計信息收集功能，該參數只對超級用戶和會話所有者可見，默認值爲on（開啓）。
#track_counts：表示是否對數據庫活動開啓統計信息收集功能，由於在AutoVacuum自動清理進程中選擇清理的數據庫時，需要數據庫的統計信息，因此該參數默認值爲on。
#track_io_timing：定時調用數據塊I/O，默認是off，因爲設置爲開啓狀態會反覆的調用數據庫時間，這給數據庫增加了很多開銷。只有超級用戶可以設置
#track_functions：表示是否開啓函數的調用次數和調用耗時統計。
#track_activity_query_size：設置用於跟蹤每一個活動會話的當前執行命令的字節數，默認值爲1024，只能在數據庫啓動後設置。
#stats_temp_directory：統計信息的臨時存儲路徑。路徑可以是相對路徑或者絕對路徑，參數默認爲pg_stat_tmp，設置此參數可以減少數據庫的物理I/O，提高性能。此參數只能在postgresql.conf文件或者服務器命令行中修改。
2.8 CheckPoint（檢查點）進程
檢查點是系統設置的事務序列點，設置檢查點保證檢查點前的日誌信息刷到磁盤中。相關參數如下：
#checkpoint_timeout = 5min # range 30s-1d
#max_wal_size = 1GB
#min_wal_size = 80MB
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
#checkpoint_flush_after = 256kB # measured in pages, 0 disables
#checkpoint_warning = 30s # 0 disables
#checkpoint_timeout ：生成檢查點的最大的間隔時間。
#checkpoint_completion_target 參數表示checkpoint的完成目標，系統默認值是0.5,也就是說每個checkpoint需要在checkpoints間隔時間的50%內完成。
PostgreSQL 9.5 廢棄了checkpoint_segments 參數, 並引入max_wal_size 和 min_wal_size 參數, 通過max_wal_size和checkpoint_completion_target參數來控制產生多少個XLOG後觸發檢查點, 通過min_wal_size和max_wal_size參數來控制哪些XLOG可以循環使用.