链接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。