PostgreSQL配置優化
- 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關閉，但是這樣就會在掉電的情況下，可能會丟失部分資料，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/200795.html
標籤：其他
下一篇：mysql 資料表的增刪改查