我正试图修复一个高PostgreSQL CPU使用问题。 我们使用的是PostgreSQL 8.0.9，当我们的JEE Web应用程序（在JBoss中）用于某些负载增加的情况时，top显示PostgreSQL的进程缓慢增加。 出现问题时，大约有12-15个PostgreSQL进程在进程信息的最右侧显示SELECT，每个进程的CPU使用率大约为6-7％，然后应用程序变慢了很多。
JBoss版本：JBoss（MX MicroKernel）4.0.3
操作系统：CentOS Linux 5.5
内核和CPU：x86_64上的Linux 2.6.18-194.26.1.el5
处理器信息：2个Intel（R）Xeon（R）CPU E5420 @ 2.50GHz，8个内核
目前，我们的想法是投入更多的硬件。 如果我们这样做，最好的select是像下面的选项A还是选项B？
选项A：4个AMD Opteron™6100系列处理器，每个处理器有12个内核
选项B：4个Intel®Xeon®7500系列处理器，每个处理器8个内核
假设使用PostgreSQL 8.0.9的CentOS Linux 5.5可以按比例增加这么多的处理器和内核（每个内核有12个内核的处理器），是否正确？ 还有什么我应该考虑投掷更多的硬件？
这个问题是不可能回答的，我们不知道发生了什么事情。 你正在谈论12-15个连接，那几乎没有。 但是，当执行非常复杂的查询时，或者使用错误的数据库模式，缺less索引等时，CPU使用率会随时增加。
8.0.9版本是严重的问题，2010年10月的版本是8.0，最新的版本是8.0.26（8.0.9之后4年的bug修复）。 你至less应该更新到这个版本，以解决8.0中的许多错误。
开始logging查询，使用EXPLAIN查看查询计划，查看VACUUM，也可能需要REINDEX。 你的硬件现在看起来很好，你首先必须find问题的根源。
考虑雇用一个PostgreSQL dba几天。
如果您显示CPU使用率过高，可能是由于查询速度慢。 我build议在postmaster.conf启用慢速查询loggingfunction，并检查比他们应该花费的时间更长的查询。
这也有可能是你I / O绑定，因为慢磁盘可以很容易地导致查询开始备份。 我会build议安装htop并检查你的CPU等待时间的百分比归因于iowait。
除此之外，我强烈鼓励升级到最新版本。 从8.0开始，性能已经有了很大的提升，当前的稳定版本（编写本文时为9.0.x）提供了更多的信息，当解释EXPLAIN VERBOSE ANALYZE查询。
一般来说（和所有其他条件相同），PostgreSQL在添加内核时可以很好地扩展（每增加一个内核，性能就会提高大约96％（每增加一个内核就可以获得理论上的100％性能提升））。
但我最初的直觉是你的磁盘跟不上。
出现问题时，大约有12-15个PostgreSQL进程在进程信息的最右侧显示SELECT，每个进程的CPU使用率大约为6-7％，然后应用程序变慢了很多。
12×6 = 72％，即使在最低点，CPU也相当繁忙。 抛出其他所有的东西，这很清楚为什么你平坦的运行。 （这是假设你将CPU视为一个聚集;当你查看处理时间时，你是按下1键来查看所有的CPU时间，或者只是看它显示的数字，全部CPU合起来了吗？）
目前，我们的想法是投入更多的硬件。 如果我们这样做，最好的select是像下面的选项A还是选项B？
选项A：4个AMD Opteron™6100系列处理器，每个处理器有12个内核
选项B：4个Intel®Xeon®7500系列处理器，每个处理器8个内核
更多的核心。 PostgreSQL将使用每个内核模型，所以越多越好。 我想看看可能是2个AMD CPU，每个12个，总共24个内核，然后随着时间的推移购买剩余的2个CPU，
假设使用PostgreSQL 8.0.9的CentOS Linux 5.5可以按比例增加这么多的处理器和内核（每个内核有12个内核的处理器），是否正确？
是。 我可能会弄错，但是我相信较老的内核编译在C头文件中使用了一个固定的数字来确定要查找的最大CPU数量，在编译时通常有一个32的上限。 如果你有一个“大”的机器，你只是将数字碰到更高的地方并重新编译。 不完全确定，但我认为他们在2.6系列中删除了这个常数，所以你应该没问题。
还有什么我应该考虑投掷更多的硬件？
在投掷硬件之前（或者调整硬件并获得新的硬件），您可能希望先调整一下软件。
如果它是一个SELECT语句，那么你可以logging它然后使用EXPLAIN来查找它在哪里花费时间？ 使用PgAdmin手动运行和调整查询，直到可以缩短执行时间。 如果SELECT语句是编程式的，您仍然可以看看使用新索引的影响。
你分配给PostgreSQL多less内存？ 每个进程多less钱？ 共享内存分配了多less？ 所有这些都会对数据库的运行造成不利影响。
是否有任何其他进程或服务可以禁用（释放内存）或重新启动（以减lessCPU消耗）？
我最近在一个小型数据库（7个表，30MB）上遇到类似的问题，查询有很多连接。 该机器是一个2GB内存的虚拟机，似乎总是使用不到160MB。 在我们添加了大约1百万条新数据之前，速度非常快。 然后，服务器（8.4.5）开始在5秒到30分钟之间的任何地方使用相同的查询次数达到100％的CPU。
我们设法通过服务器升级来解决这个问题。 8.4.9和8.4.12的testing没有显示不良行为（但8.4.8）。
我想你会从PostgreSQL 9.0 High Performance这本书中受益。 它以PDF（即时下载）以及死树格式提供。
我们刚刚使用本书中的build议重build了我们的数据库。 我们新的数据库箱子将旧的数据库打开，我们不必花费大量的钱。 有几个章节专门解决你的每个问题。 有答案，但更好的是，也有方法（你如何衡量你的硬件知道它有多快？）
我不是Postgresql的专家，但我会告诉你我已经了解了硬件和Postgresql。 你的旅费可能会改变。
一般来说，对于我有经验的数据库来说，比CPU的数量和速度更重要的是：
你用RAID获得I / O带宽。 对于Postgresql的大部分数据来说，RAID10都是不错的select。 驱动器越多，性能越好。 把xlog放在一个单独的设备上，如果可以的话。 那个可以是RAID1。 使用带有电池支持的高速caching的硬件RAID卡将为您提供最佳的性能。