PostgreSQL配置優化

硬件和系統配置

操做系統	Ubuntu13.04
系統位數	64
CPU	Intel(R) Core(TM)2 Duo CPU
內存	4G
硬盤	Seagate ST2000DM001-1CH164
測試工具	PostgreSQL-9.1.11

測試工具

工具名稱	pgbench
數據量	200W（整個數據庫大小約爲300M）
模擬客戶端數	4
線程數	4
測試時間	60秒

• 準備命令：pgbench -i -s 20 pgbenchdb

• 測試命令：pgbench -r -j4 -c4 -T60 testdb

配置文件

默認的配置配置文件是保存在/etc/postgresql/VERSION/main目錄下的postgresql.conf文件

• 若是想查看參數修改是否生效，能夠用psql鏈接到數據庫後，用<show 選項名> 來查看。

• 若是要修改shared_buffers， 在ubuntu下可能須要執行命令<sysctl -w>Managing Kernel Resources

主要選項

選項	默認值	說明	是否優化	緣由
max_connections	100	容許客戶端鏈接的最大數目	否	由於在測試的過程當中，100個鏈接已經足夠
fsync	on	強制把數據同步更新到磁盤	是	由於系統的IO壓力很大，爲了更好的測試其餘配置的影響，把改參數改成off
shared_buffers	24MB	決定有多少內存能夠被PostgreSQL用於緩存數據（推薦內存的1/4)	是	在IO壓力很大的狀況下，提升該值能夠減小IO
work_mem	1MB	使內部排序和一些複雜的查詢都在這個buffer中完成	是	有助提升排序等操做的速度，而且減低IO
effective_cache_size	128MB	優化器假設一個查詢能夠用的最大內存，和shared_buffers無關（推薦內存的1/2)	是	設置稍大，優化器更傾向使用索引掃描而不是順序掃描
maintenance_work_mem	16MB	這裏定義的內存只是被VACUUM等耗費資源較多的命令調用時使用	是	把該值調大，能加快命令的執行
wal_buffer	768kB	日誌緩存區的大小	是	能夠下降IO，若是趕上比較多的併發短事務，應該和commit_delay一塊兒用
checkpoint_segments	3	設置wal log的最大數量數（一個log的大小爲16M）	是	默認的48M的緩存是一個嚴重的瓶頸，基本上都要設置爲10以上
checkpoint_completion_target	0.5	表示checkpoint的完成時間要在兩個checkpoint間隔時間的N%內完成	是	能下降平均寫入的開銷
commit_delay	0	事務提交後，日誌寫到wal log上到wal_buffer寫入到磁盤的時間間隔。須要配合commit_sibling	是	可以一次寫入多個事務，減小IO，提升性能
commit_siblings	5	設置觸發commit_delay的併發事務數，根據併發事務多少來配置	是	減小IO，提升性能

測試數據

• 測試的數據是運行3次，取平均值。

• 關閉fsync是爲了更好的體現出其餘參數對PostgreSQL的影響。

參數	修改值	事務總數	tps(包括創建鏈接)	tps(不包括創建鏈接)
默認設置		8464	140.999792	141.016182
fsync	off	92571	1479.969755	1480.163355
shared_buffers	1GB	100055	1635.759275	1635.977823
work_mem	10MB	101209	1665.804812	1666.04082
effective_cache_size	2GB	98209	1636.733152	1636.970271
maintenance_work_mem	512MB	92930	1548.029233	1548.223108
checkpoint_segments	32	195982	3265.995	3266.471064
checkpoint_completion_target	0.9	194390	3239.406493	3239.842596
wal_buffer	8MB	198639	3310.241458	3310.724067
恢復fsync	off	11157	185.883542	185.909849
commit_delay && commit_siblings	10 && 4	11229	187.103538	187.131747

總結

	事務總數	tps(包括創建鏈接)	tps(不包括創建鏈接)
優化前	8464	140.999792	141.016182
優化後(fsync=on)	11229	187.103538	187.131747
優化後(fsync=off)	198639	3310.241458	3310.724067

在fsync打開的狀況下，優化後性能可以提高30%左右。由於有部分優化選項在默認的SQL測試語句中沒有體現出它的優點，若是到實際測試中，提 升應該不止30%。 測試的過程當中，主要的瓶頸就在系統的IO，若是須要減小IO的負荷，最直接的方法就是把fsync關閉，可是這樣就會在掉電的狀況下，可能會丟失部分數 據。