在使用postgresql
過程當中如果併發比較高,並且資料量也比較大的時候需要對配置項做一些最佳化
實際的postgresql
預設配置比較保守,所以如果機器硬體配置還可以的話可以大幅度改動
最佳化配置項
不同版本下的配置預設值是不一樣的,具體以官方文件為準
以下配置是pg14版本
max_connections
- 預設值100
- 允許的最大客戶端連線數,通常可以配置上百上千個連線,併發不是太高的話100夠用了
shared_buffers
- 增大資料庫記憶體使用效率
- 設定資料庫伺服器將使用的共享記憶體緩衝區量,預設
128MB
- 決定有多少記憶體可以被
PostgreSQL
用於快取資料 - 推薦記憶體的1/4
- 在磁碟
IO
壓力很大的情況下,提高該值可以減少磁碟IO
work_mem
- 加快查詢排序
- 預設
4M
- 設定在寫入臨時磁碟檔案之前查詢操作(例如排序或雜湊表)可使用的基礎最大記憶體容量
ORDER BY
、DISTINCT
和歸併連線都要用到排序操作,雜湊連線、基於雜湊的聚集以及基於雜湊的IN
子查詢處理中都要用到雜湊表,使內部排序和一些複雜的查詢都在這個
buffer
中完成,有助提高排序等操作的速度,並且降低IO
這個引數和
max_connections
有關,如果100個查詢併發,最壞情況下就很快就達到400M
的記憶體使用,work_mem
*max_connections
需要小於記憶體,推薦乘積可以保持在記憶體的1/2
和3/4
之間
effective_cache_size
- 加快查詢
- 預設
4G
,該配置不實際佔用記憶體,最佳化器假設一個查詢可以用的最大記憶體,保守推薦配置為實體記憶體的1/2
,更加推薦配置為記憶體的3/4
- 設定變大,最佳化器更傾向使用索引掃描而不是順序掃描
max_wal_size
- 避免頻繁的進行檢查點,減少磁碟
IO
- 預設
1G
wal
全稱是write ahead log
,是postgresql
中的online redo log
,保證資料的一致性和事務的完整性- 在自動
WAL
檢查點之間允許WAL
增長到的最大尺寸 - 中心思想是先寫日誌後寫資料,即要保證對資料庫檔案的修改應放生在這些修改已經寫入到日誌之後
- 使用
wal
可以顯著減少磁碟寫操作的數量,因為只需要將日誌檔案重新整理到磁碟以確保提交事務,而不是事務更改的每個資料檔案,日誌檔案是按順序寫入的,因此同步日誌的成本要比重新整理資料頁的成本低得多 - 如果在資料庫的日誌當中看到告警如
consider increasing the configuration parameter "max_wal_size"
,則確實需要增大該引數,在高負載情況下,日誌很快就會達到1G
,推薦把該引數配置為32G
或者以上
wal_buffers
- 加快資料更新操作
- 預設
4M
- 配置
wal
使用的共享記憶體大小,可以改成1G
配置方式
修改資料庫配置可以透過修改postgresql.conf
檔案或者修改啟動命令等方式
修改檔案方式
在postgresql
的docker
容器當中
postgresql.conf
的檔案位置是/var/lib/postgresql/data/postgresql.conf
,如果找不到可以執行如下命令搜尋一下
$ find / -name "postgresql.conf" 2>/dev/null
在修改完成該配置檔案之後直接掛載進去啟動容器就行
修改啟動命令方式
該方式簡單直接
比如修改最大連線數量,配置啟動命令為postgres -c max_connections=500
即可
檢查配置是否生效
最終經過最佳化,修改pg
的啟動命令改為
$ postgres -c max_connections=500 -c shared_buffers=1GB -c work_mem=128MB -c max_wal_size=64GB -c wal_buffers=1GB
進入到psql
環境下面執行show
命令驗證
# show max_connections ;
max_connections
-----------------
500
(1 row)
或者使用show all
檢視所有配置