由于是开发阶段，所以并没有配置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的关系。

有关参数的解释可见： 和 。

4，硬件的选择

由于计算机硬件大多数是兼容的，人们总是倾向于相信所有计算机硬件质量也是相同的。

事实上不是， ECC RAM（带奇偶校验的内存），SCSI （硬盘）和优质的主板比一些便宜货要更加可靠且具有更好的性能。

PostgreSQL几乎可以运行在任何硬件上，但如果可靠性和性能对你的系统很重要，你就需要全面的研究一下你的硬件配置了。

计算机硬件对性能的影响可浏览 和 。

5，为什么在试图连接时收到“Sorry, too many clients”消息？

这表示你已达到缺省100个并发后台进程数的限制，

你需要通过修改postgresql.conf文件中的max_connections值来增加postmaster的后台并发处理数，修改后需重新启动postmaster。