pg幾個重要的引數調優

pg資料庫在不同的業務場景下，引數最好也需要進行針對的調整。預設值是在確保資源消耗最小的情況下，pg都能夠執行起來，不會導致任何致命性的威脅。而實際中，預設的引數需要進行優化來達到效能的最大化，本文介紹一些常用的引數配置。

pg資料庫預設安裝完後在data目錄會有乙個postgresql.conf檔案，這個裡面有非常多的引數來配置資料庫。

postgresql既使用自身的緩衝區，也使用核心緩衝io。這意味著資料會在記憶體中儲存兩次，首先是存入postgresql緩衝區，然後是核心緩衝區。這被稱為雙重緩衝區處理。對大多數作業系統來說，這個引數是最有效的用於調優的引數。此引數的作用是設定postgresql中用於快取的專用記憶體量。

shared_buffers的預設值設定得非常低，因為某些機器和作業系統不支援使用更高的值。但在大多數現代裝置中，通常需要增大此引數的值才能獲得最佳效能。

建議的設定值為機器總記憶體大小的25％，但是也可以根據實際情況嘗試設定更低和更高的值。實際值取決於機器的具體配置和工作的資料量大小。舉個例子，如果工作資料集可以很容易地放入記憶體中，那麼可以增加shared_buffers的值來包含整個資料庫，以便整個工作資料集可以保留在快取中。

在生產環境中，將shared_buffers設定為較大的值通常可以提供非常好的效能，但應當時刻注意找到平衡點。

檢視當前shared_buffers的值：

postgres=# show shared_buffers;
shared_buffers 
----------------
128mb

postgresql將其wal（預寫日誌）記錄寫入緩衝區，然後將這些緩衝區重新整理到磁碟。由wal_buffers定義的緩衝區的預設大小為16mb，但如果有大量併發連線的話，則設定為乙個較高的值可以提供更好的效能。

檢視當前wal_buffers的值：

postgres=# show wal_buffers;
wal_buffers
-------------
4mb(1 行記錄)

effective_cache_size提供可用於磁碟快取記憶體的記憶體量的估計值。它只是乙個建議值，而不是確切分配的記憶體或快取大小。它不會實際分配記憶體，而是會告知優化器核心中可用的快取量。在乙個索引的代價估計中，更高的數值會使得索引掃瞄更可能被使用，更低的數值會使得順序掃瞄更可能被使用。在設定這個引數時，還應該考慮postgresql的共享緩衝區以及將被用於postgresql資料檔案的核心磁碟緩衝區。預設值是4gb。

檢視當前effective_cache_size的值：

postgres=# show effective_cache_size;
effective_cache_size
----------------------
4gb(1 行記錄)

此配置用於復合排序。記憶體中的排序比溢位到磁碟的排序快得多，設定非常高的值可能會導致部署環境出現記憶體瓶頸，因為此引數是按使用者排序操作。如果有多個使用者嘗試執行排序操作，則系統將為所有使用者分配大小為work_mem *總排序運算元的空間。全域性設定此引數可能會導致記憶體使用率過高，因此強烈建議在會話級別修改此引數值。預設值為4mb。

檢視當前work_mem的值：

postgres=# show work_mem;
work_mem
----------
4mb(1 行記錄)

maintenance_work_mem是用於維護任務的記憶體設定。預設值為64mb。設定較大的值對於vacuum，restore，create index，add foreign key和alter table等操作的效能提公升效果顯著。

檢視當前maintenance_work_mem的值：

postgres=# show maintenance_work_mem;
maintenance_work_mem
----------------------
64mb
(1 行記錄)

此引數的作用為在向客戶端返回成功狀態之前，強制提交等待wal被寫入磁碟。這是效能和可靠性之間的權衡。如果應用程式被設計為效能比可靠性更重要，那麼關閉synchronous_commit。這意味著成功狀態與保證寫入磁碟之間會存在時間差。在伺服器崩潰的情況下，即使客戶端在提交時收到成功訊息，資料也可能丟失。

檢視當前synchronous_commit的設定值：

postgres=# show synchronous_commit;
synchronous_commit
--------------------
on(1 行記錄)

postgresql將更改寫入wal。檢查點程序將資料重新整理到資料檔案中。發生checkpoint時完成此操作。這是一項開銷很大的操作，整個過程涉及大量的磁碟讀/寫操作。使用者可以在需要時隨時發出checkpoint指令，或者通過postgresql的引數checkpoint_timeout和checkpoint_completion_target來自動完成。

checkpoint_timeout引數用於設定wal檢查點之間的時間。將此設定得太低會減少崩潰恢復時間，因為更多資料會寫入磁碟，但由於每個檢查點都會占用系統資源，因此也會損害效能。此引數只能在postgresql.conf檔案中或在伺服器命令列上設定。

checkpoint_completion_target指定檢查點完成的目標，作為檢查點之間總時間的一部分。預設值是 0.5。這個引數只能在postgresql.conf檔案中或在伺服器命令列上設定。高頻率的檢查點可能會影響效能。

檢視當前checkpoint_timeout和checkpoint_completion_target的值：

checkpoint_completion_target指定檢查點完成的目標，作為檢查點之間總時間的一部分。預設值是 0.5。

這個引數只能在postgresql.conf檔案中或在伺服器命令列上設定。高頻率的檢查點可能會影響效能。

檢視當前checkpoint_timeout和checkpoint_completion_target的值：

postgres=# show checkpoint_timeout;
checkpoint_timeout
--------------------
5min
(1 行記錄)
postgres=# show checkpoint_completion_target;
checkpoint_completion_target
------------------------------
0.5(1 行記錄)

該引數主要是控制wal檔案的數量，對於頻繁的更改資料庫的業務場景下，wal日誌短時間會非常多，對應的目錄是pg_xlog，有時候，該目錄的大小可能為幾十上百g，很快就將磁碟變滿。因此為了合理控制該目錄的大小，一般會將wal_keep_segments控制在乙個合理的範圍內。因為該引數如果過小的話，會影響到資料庫的啟動或者流複製。如果過大的話，就是前面所說的，導致wal日誌非常多，占用的空間會非常大，預設系統是為0，表示資料庫不儲存任何wal日誌，但是實際中還是會有少量的產生。

檢視當前的wal_keep_segments值：

postgres=# show wal_keep_segments;
wal_keep_segments
-------------------
0(1 行記錄)

當然，還要很多其他的引數，本文參考了網上的一些資料進行了整理。pg資料庫目前在中國遠沒有mysql那麼流行，但是作為oracle的最佳替代開源資料庫，pg一直在改進，相信pg相關的資料會越來越多，這也需要大家不斷去嘗試，不斷共享自己使用pg的經驗。

pg幾個重要的引數調優

PG引數調優

Hadoop調優的幾個引數

Dubbo 併發調優的幾個引數

pg幾個重要的引數調優

PG引數調優

Hadoop調優的幾個引數

Dubbo 併發調優的幾個引數

相關推薦