postgresql调优
http://blog.pgaddict.com/posts/performance-since-postgresql-7-4-to-9-4-pgbench
硬件和系統(tǒng)配置
| 操作系統(tǒng) | Ubuntu13.04 |
| 系統(tǒng)位數(shù) | 64 |
| CPU | Intel(R) Core(TM)2 Duo CPU |
| 內(nèi)存 | 4G |
| 硬盤 | Seagate ST2000DM001-1CH164 |
| 測(cè)試工具 | PostgreSQL-9.1.11 |
測(cè)試工具
| 工具名稱 | pgbench |
| 數(shù)據(jù)量 | 200W（整個(gè)數(shù)據(jù)庫大小約為300M） |
| 模擬客戶端數(shù) | 4 |
| 線程數(shù) | 4 |
| 測(cè)試時(shí)間 | 60秒 |
準(zhǔn)備命令：pgbench -i -s 20 pgbenchdb
測(cè)試命令：pgbench -r -j4 -c4 -T60 testdb
配置文件
默認(rèn)的配置配置文件是保存在/etc/postgresql/VERSION/main目錄下的postgresql.conf文件
如果想查看參數(shù)修改是否生效，可以用psql連接到數(shù)據(jù)庫后，用<show 選項(xiàng)名> 來查看。
如果要修改shared_buffers， 在ubuntu下可能需要執(zhí)行命令<sysctl -w>Managing Kernel Resources
主要選項(xiàng)
| 選項(xiàng) | 默認(rèn)值 | 說明 | 是否優(yōu)化 | 原因 |
| max_connections | 100 | 允許客戶端連接的最大數(shù)目 | 否 | 因?yàn)樵跍y(cè)試的過程中，100個(gè)連接已經(jīng)足夠 |
| fsync | on | 強(qiáng)制把數(shù)據(jù)同步更新到磁盤 | 是 | 因?yàn)橄到y(tǒng)的IO壓力很大，為了更好的測(cè)試其他配置的影響，把改參數(shù)改為off |
| shared_buffers | 24MB | 決定有多少內(nèi)存可以被PostgreSQL用于緩存數(shù)據(jù)（推薦內(nèi)存的1/4) | 是 | 在IO壓力很大的情況下，提高該值可以減少IO |
| work_mem | 1MB | 使內(nèi)部排序和一些復(fù)雜的查詢都在這個(gè)buffer中完成 | 是 | 有助提高排序等操作的速度，并且減低IO |
| effective_cache_size | 128MB | 優(yōu)化器假設(shè)一個(gè)查詢可以用的最大內(nèi)存，和shared_buffers無關(guān)（推薦內(nèi)存的1/2) | 是 | 設(shè)置稍大，優(yōu)化器更傾向使用索引掃描而不是順序掃描 |
| maintenance_work_mem | 16MB | 這里定義的內(nèi)存只是被VACUUM等耗費(fèi)資源較多的命令調(diào)用時(shí)使用 | 是 | 把該值調(diào)大，能加快命令的執(zhí)行 |
| wal_buffer | 768kB | 日志緩存區(qū)的大小 | 是 | 可以降低IO，如果遇上比較多的并發(fā)短事務(wù)，應(yīng)該和commit_delay一起用 |
| checkpoint_segments | 3 | 設(shè)置wal log的最大數(shù)量數(shù)（一個(gè)log的大小為16M） | 是 | 默認(rèn)的48M的緩存是一個(gè)嚴(yán)重的瓶頸，基本上都要設(shè)置為10以上 |
| checkpoint_completion_target | 0.5 | 表示checkpoint的完成時(shí)間要在兩個(gè)checkpoint間隔時(shí)間的N%內(nèi)完成 | 是 | 能降低平均寫入的開銷 |
| commit_delay | 0 | 事務(wù)提交后，日志寫到wal log上到wal_buffer寫入到磁盤的時(shí)間間隔。需要配合commit_sibling | 是 | 能夠一次寫入多個(gè)事務(wù)，減少IO，提高性能 |
| commit_siblings | 5 | 設(shè)置觸發(fā)commit_delay的并發(fā)事務(wù)數(shù)，根據(jù)并發(fā)事務(wù)多少來配置 | 是 | 減少IO，提高性能 |
測(cè)試數(shù)據(jù)
測(cè)試的數(shù)據(jù)是運(yùn)行3次，取平均值。
關(guān)閉fsync是為了更好的體現(xiàn)出其他參數(shù)對(duì)PostgreSQL的影響。
| 參數(shù) | 修改值 | 事務(wù)總數(shù) | tps(包括建立連接) | tps(不包括建立連接) |
| 默認(rèn)設(shè)置 | 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 |
| 恢復(fù)fsync | off | 11157 | 185.883542 | 185.909849 |
| commit_delay && commit_siblings | 10 && 4 | 11229 | 187.103538 | 187.131747 |
總結(jié)
| 事務(wù)總數(shù) | tps(包括建立連接) | tps(不包括建立連接) | |
| 優(yōu)化前 | 8464 | 140.999792 | 141.016182 |
| 優(yōu)化后(fsync=on) | 11229 | 187.103538 | 187.131747 |
| 優(yōu)化后(fsync=off) | 198639 | 3310.241458 | 3310.724067 |
在fsync打開的情況下，優(yōu)化后性能能夠提升30%左右。因?yàn)橛胁糠謨?yōu)化選項(xiàng)在默認(rèn)的SQL測(cè)試語句中沒有體現(xiàn)出它的優(yōu)勢(shì)，如果到實(shí)際測(cè)試中，提升應(yīng)該不止30%。 測(cè)試的過程中，主要的瓶頸就在系統(tǒng)的IO，如果需要減少IO的負(fù)荷，最直接的方法就是把fsync關(guān)閉，但是這樣就會(huì)在掉電的情況下，可能會(huì)丟失部分?jǐn)?shù)據(jù)。
-------------------------------------------------------------------------------
pg中性能相關(guān)常調(diào)參數(shù)
??
?
| 參數(shù)名稱 | 參數(shù)意義 | 優(yōu)化思路 |
| shared_buffers | 數(shù)據(jù)庫服務(wù)器將使用的共享內(nèi)存緩沖區(qū)大小，該緩沖區(qū)為所有連接共用。從磁盤讀入的數(shù)據(jù)（主要包括表和索引）都緩存在這里。 | 提高該值可以減少數(shù)據(jù)庫的磁盤IO。 |
| work_mem | 聲明內(nèi)部排序和哈希操作可使用的工作內(nèi)存大小。該內(nèi)存是在開始使用臨時(shí)磁盤文件之前使用的內(nèi)存數(shù)目。數(shù)值以kB為單位的，缺省是?1024 (1MB)。請(qǐng)注意對(duì)于復(fù)雜的查詢，可能會(huì)同時(shí)并發(fā)運(yùn)行好幾個(gè)排序或者哈希操作，每個(gè)都會(huì)使用這個(gè)參數(shù)聲明的這么多內(nèi)存，然后才會(huì)開始求助于臨時(shí)文件。同樣，好幾個(gè)正在運(yùn)行的會(huì)話可能會(huì)同時(shí)進(jìn)行排序操作。因此使用的總內(nèi)存可能是?work_mem?的好幾倍。ORDER BY, DISTINCT?和mergejoin都要用到排序操作，而哈希操作在哈希連接、哈希聚集和以哈希為基礎(chǔ)的?IN?子查詢處理中都會(huì)用到。該參數(shù)是會(huì)話級(jí)參數(shù)。 | 執(zhí)行排序操作時(shí)，會(huì)根據(jù)work_mem的大小決定是否將一個(gè)大的結(jié)果集拆分為幾個(gè)小的和?work_mem差不多大小的臨時(shí)文件寫入外存。顯然拆分的結(jié)果是導(dǎo)致了IO，降低了排序的速度。因此增加work_mem有助于提高排序的速度。通常設(shè)置時(shí)可以逐漸調(diào)大，知道數(shù)據(jù)庫在排序的操作時(shí)不會(huì)有大量的寫文件操作即可。該內(nèi)存每個(gè)連接一份，當(dāng)并發(fā)連接較多時(shí)候，該值不宜過大。 |
| effective_cache_size | 優(yōu)化器假設(shè)一個(gè)查詢可以使用的最大內(nèi)存（包括pg使用的和操作系統(tǒng)緩存），和shared_buffer等內(nèi)存無關(guān)，只是給優(yōu)化器生成計(jì)劃使用的一個(gè)假設(shè)值。 | 設(shè)置稍大，優(yōu)化器更傾向使用索引掃描而不是順序掃描，建議的設(shè)置為可用空閑內(nèi)存的25%，這里的可用空閑內(nèi)存指的是主機(jī)物理內(nèi)存在運(yùn)行pg時(shí)得空閑值。 |
| maintenance_work_mem | 這里定義的內(nèi)存只是在CREATE INDEX, VACUUM等時(shí)用到，因此用到的頻率不高，但是往往這些指令消耗比較多的資源，因此應(yīng)該盡快讓這些指令快速執(zhí)行完畢。 | 在數(shù)據(jù)庫導(dǎo)入數(shù)據(jù)后，執(zhí)行建索引等操作時(shí)，可以調(diào)大，比如512M。 |
| wal_buffers | 日志緩沖區(qū)，日志緩沖區(qū)的大小。 | 兩種情況下要酌情調(diào)大：1.單事務(wù)的數(shù)據(jù)修改量很大，產(chǎn)生的日志大于wal_buffers，為了避免多次IO，調(diào)大該值。 2.系統(tǒng)中并發(fā)小數(shù)據(jù)量修改的短事務(wù)較多，并且設(shè)置了commit_delay，此時(shí)wal_buffers需要容納多個(gè)事務(wù)（commit_siblings個(gè)）的日志，調(diào)大該值避免多次IO。 |
| commit_delay | 事務(wù)提交后，日志寫到wal_buffer上到wal_buffer寫到磁盤的時(shí)間間隔。 | 如果并發(fā)的非只讀事務(wù)數(shù)目較多，可以適當(dāng)增加該值，使日志緩沖區(qū)一次刷盤可以刷出較多的事務(wù)，減少IO次數(shù)，提高性能。需要和commit_sibling配合使用。 |
| commit_siblings | 觸發(fā)commit_delay等待的并發(fā)事務(wù)數(shù)，也就是系統(tǒng)的并發(fā)活躍事務(wù)數(shù)達(dá)到了該值事務(wù)才會(huì)等待commit_delay的時(shí)間才將日志刷盤，如果系統(tǒng)中并發(fā)活躍事務(wù)達(dá)不到該值，commit_delay將不起作用，防止在系統(tǒng)并發(fā)壓力較小的情況下事務(wù)提交后空等其他事務(wù)。 | 應(yīng)根據(jù)系統(tǒng)并發(fā)寫的負(fù)載配置。例如統(tǒng)計(jì)出系統(tǒng)并發(fā)執(zhí)行增刪改操作的平均連接數(shù)，設(shè)置該值為該平均連接數(shù)。 |
| fsync | 設(shè)置為on時(shí)，日志緩沖區(qū)刷盤時(shí)，需要確認(rèn)已經(jīng)將其寫入了磁盤，設(shè)置為off時(shí)，由操作系統(tǒng)調(diào)度磁盤寫的操作，能更好利用緩存機(jī)制，提高IO性能。 | 該性能的提高是伴隨了數(shù)據(jù)丟失的風(fēng)險(xiǎn)，當(dāng)操作系統(tǒng)或主機(jī)崩潰時(shí)，不保證刷出的日志是否真正寫入了磁盤。應(yīng)依據(jù)操作系統(tǒng)和主機(jī)的穩(wěn)定性來配置。 |
| autovacuum | 是否開啟自動(dòng)清理進(jìn)程（如開啟需要同時(shí)設(shè)置參數(shù)stats_start_collector = on，stats_row_level = on，），整理數(shù)據(jù)文件碎片，更新統(tǒng)計(jì)信息。 | 如果系統(tǒng)中有大量的增刪改操作，建議打開自動(dòng)清理進(jìn)程，這樣一方面可以增加數(shù)據(jù)文件的物理連續(xù)性，減少磁盤的隨機(jī)IO，一方面可以隨時(shí)更新數(shù)據(jù)庫的統(tǒng)計(jì)信息，使優(yōu)化器可以選擇最優(yōu)的查詢計(jì)劃得到最好的查詢性能。如果系統(tǒng)中只有只讀的事務(wù)，那么關(guān)閉自動(dòng)清理進(jìn)程。 |
| autovacuum_naptime | 自動(dòng)清理進(jìn)程執(zhí)行清理分析的時(shí)間間隔 | 應(yīng)該根據(jù)數(shù)據(jù)庫的單位時(shí)間更新量來決定該值，一般來說單位時(shí)間的更新量越大該時(shí)間間隔應(yīng)該設(shè)置越短。由于自動(dòng)清理對(duì)系統(tǒng)的開銷較大，該值應(yīng)該謹(jǐn)慎配置（不要過小）。 |
| bgwriter_delay | 后臺(tái)寫進(jìn)程的自動(dòng)執(zhí)行時(shí)間 | 后臺(tái)寫進(jìn)程的作用是將shared_buffer里的臟頁面寫回到磁盤，減少checkpoint的壓力，如果系統(tǒng)數(shù)據(jù)修改的壓力一直很大，建議將該時(shí)間間隔設(shè)置小一些，以免積累的大量的臟頁面到checkpoint，使checkpoint時(shí)間過長(zhǎng)（checkpoint期間系統(tǒng)響應(yīng)速度較慢）。 |
| bgwriter_lru_maxpages | 后臺(tái)寫進(jìn)程一次寫出的臟頁面數(shù) | 依據(jù)系統(tǒng)單位時(shí)間數(shù)據(jù)的增刪改量來修改 |
| bgwriter_lru_multiplier | 后臺(tái)寫進(jìn)程根據(jù)最近服務(wù)進(jìn)程需要的buffer數(shù)量乘上這個(gè)比率估算出下次服務(wù)進(jìn)程需要的buffer數(shù)量，在使用后臺(tái)寫進(jìn)程寫回臟頁面，使緩沖區(qū)能使用的干凈頁面達(dá)到這個(gè)估計(jì)值。 | 依據(jù)系統(tǒng)單位時(shí)間數(shù)據(jù)的增刪改量來修改。 |
?
2。 tpcc/壓力測(cè)試時(shí)pg常調(diào)參數(shù)示例:
?
max_connections = 200
?
#根據(jù)數(shù)據(jù)量盡量調(diào)大shared_buffer值，把所有數(shù)據(jù)都放到內(nèi)存中更好，
#曾經(jīng)在32G內(nèi)存的服務(wù)器上把shared_buffert調(diào)到了26G?
#wal_buffers根據(jù)產(chǎn)生的wal日志量也適當(dāng)設(shè)大點(diǎn)
shared_buffers=1200MB?
wal_buffers = 2000kB
#work_mem要適可而止，每個(gè)連接都要用這么大的
work_mem = 1024kB
#一般做做檢查點(diǎn)的時(shí)間長(zhǎng)于壓力測(cè)試的時(shí)間，這樣性能數(shù)據(jù)會(huì)更好，等壓力測(cè)試完了再去做檢查點(diǎn)吧。
Checkpoint_timeout=120min
?
bgwriter_delay = 10ms??
bgwriter_lru_maxpages = 75
full_page_writes = off
log_min_messages = fatal
#壓力測(cè)試時(shí)由于高并發(fā)等鎖的時(shí)間可以長(zhǎng)一些
deadlock_timeout = 3s
?
#平時(shí)實(shí)踐有些應(yīng)用中把位圖掃描和順序掃描關(guān)了性能會(huì)更好?
enable_bitmapscan = off
enable_seqscan = off
?
#如果是只讀的壓力測(cè)試，還可以關(guān)掉沒事的后臺(tái)寫進(jìn)程等
轉(zhuǎn)載于:https://blog.51cto.com/shuizhuan/1660632
總結(jié)
以上是生活随笔為你收集整理的postgresql调优的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： TOUGHRADIUS 项目介绍
- 下一篇： iOS开发网络篇—Reachabilit