鏈接postgres特別消耗cpu資源而引起的PostgreSQL性能優化考慮

因爲是開發階段，因此並無配置postgres的參數，都是使用安裝時的默認配置，
之前運行也不見得有什麼不正常，但是前幾天個人cpu資源佔用忽然升高.
查看進程，發現有一個postgres的進程佔用CPU都是80%以上，並且居高不下；

剛開始覺得是配置上須要修改，但事實上，默認配置基本上是很優化的，並且是開發階段，數據量也並不大。
後來經過分析，得出結論，解決問題應該從如下幾個方面來逐一考慮：

1，SQL查詢方面
檢查數據檢索的索引是否創建，凡是須要查找的字段儘可能創建索引，甚至是聯合索引；
建立索引，包括表達式和部分索引；
使用COPY語句代替多個Insert語句；
將多個SQL語句組成一個事務以減小提交事務的開銷；
從一個索引中提取多條記錄時使用CLUSTER；
從一個查詢結果中取出部分記錄時使用LIMIT；
使用預編譯式查詢（Prepared Query)；
使用ANALYZE以保持精確的優化統計；
按期使用 VACUUM 或 pg_autovacuum
進行大量數據更改時先刪除索引（而後重建索引）
2，程序經驗方面
檢查程序，是否使用了鏈接池，若是沒有使用，儘快使用吧；
繼續檢查程序，鏈接使用後，是否交還給了鏈接池；
3，服務器參數配置
配置文件postgres.conf中的不少設置都會影響性能，
shared_buffers：這是最重要的參數，postgresql經過shared_buffers和內核/磁盤打交道。
所以應該儘可能大，讓更多的數據緩存在shared_buffers中，一般設置爲實際RAM的10％是合理的，好比50000(400M)
work_mem：在pgsql 8.0以前叫作sort_mem。postgresql在執行排序操做時，
會根據work_mem的大小決定是否將一個大的結果集拆分爲幾個小的和work_mem查很少大小的臨時文件。
顯然拆分的結果是下降了排序的速度。所以增長work_mem有助於提升排序的速度。一般設置爲實際RAM的2%-4%，根據須要排序結果集的大小而定，好比81920(80M)
effective_cache_size：是postgresql可以使用的最大緩存，
這個數字對於獨立的pgsql服務器而言應該足夠大，好比4G的內存，能夠設置爲3.5G(437500)
maintence_work_mem：這裏定義的內存只是在CREATE INDEX, VACUUM等時用到，所以用到的頻率不高，可是每每這些指令消耗比較多的資源，
所以應該儘快讓這些指令快速執行完畢：給maintence_work_mem大的內存，好比512M(524288)
max_connections：一般，max_connections的目的是防止max_connections * work_mem超出了實際內存大小。
好比，若是將work_mem設置爲實際內存的2%大小，則在極端狀況下，若是有50個查詢都有排序要求，並且都使用2％的內存，則會致使swap的產生，系統性能就會大大下降。
固然，若是有4G的內存，同時出現50個如此大的查詢的概率應該是很小的。不過，要清楚max_connections和work_mem的關係。
有關參數的解釋可見： http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html 和 http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html。
4，硬件的選擇
因爲計算機硬件大多數是兼容的，人們老是傾向於相信全部計算機硬件質量也是相同的。
事實上不是， ECC RAM（帶奇偶校驗的內存），SCSI （硬盤）和優質的主板比一些便宜貨要更加可靠且具備更好的性能。
PostgreSQL幾乎能夠運行在任何硬件上，但若是可靠性和性能對你的系統很重要，你就須要全面的研究一下你的硬件配置了。
計算機硬件對性能的影響可瀏覽 http://candle.pha.pa.us/main/writings/pgsql/hw_performance/index.html 和 http://www.powerpostgresql.com/PerfList/。
5，爲何在試圖鏈接時收到「Sorry, too many clients」消息？
這表示你已達到缺省100個併發後臺進程數的限制，
你須要經過修改postgresql.conf文件中的max_connections值來 增長postmaster的後臺併發處理數，修改後需從新啓動postmaster。