ted 影響 字段 出了 reat con sha 應該 effect

由於是開發階段，所以並沒有配置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。

postgresql某進程占用cpu資源過高，降不下來