PostgreSQL pg_stat_activity 显示 COMMIT

Question

我们最近用升级后的机器替换了我们的数据库服务器，该机器具有 4 个四核 CPU 和 32Gb 内存。我们还重新利用了我们的旧盒子作为流复制的奴隶。两个机器都运行 CentOS 6.3 和 PostgreSQL 9.2。Postgres 是每个盒子上唯一运行的东西。

这种配置已经存在大约一个月左右，当流量开始增加时，我们突然开始遇到一些问题。我们开始看到有时 CPU 负载非常高（顶部显示平均负载为 270），当我们可以查看时，pg_stat_activity我们将看到我们的大部分连接都处于该COMMIT状态。如果不理会，这最终将完成，系统将响应连接变为IDLE。我们已尝试禁用复制以查看是否可能是问题所在，但问题仍然存在。

我们已经尝试诊断正在发生的事情，但有点迷茫。运行的输出perf显示类似于下面的内容，我不知道0x347ba9代表什么。

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ?
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ?
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ?
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ?
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ?
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ?
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ?
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ?
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

应用程序执行的查询都不是特别复杂，解释计划最多需要 1 秒（大多数要快得多）。此外，虽然这种情况发生在流量开始增加时，但我们并不是在谈论巨大的流量负载（旧机器过去能够很容易地处理它）。

在这一点上，我对接下来要尝试的内容感到有些困惑。任何帮助或建议将不胜感激。如果有任何其他信息有帮助，请询问，我可以修改问题。

磁盘配置：

• Perc 6i RAID 控制器
• 5 个 146GB 15K SAS 驱动器
• 为 WAL 配置为 2x146GB RAID-1，为系统和数据配置为 3x146GB RAID-5

更新：

以下是系统正常运行和 CPU 启动时的 VMStat 输出。当出现问题时，中断似乎猛增。

在正常操作期间：

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

当 CPU 使用率高时：

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

Answer 1

经过进一步的诊断和一些谷歌搜索后，我们发现这篇文章描述了我们遇到的许多相同的症状。他们问题的根本原因（据我们所知，我们的问题也是如此）与Transparent Huge Pages实施有关。

Transparent Huge Pages使用此命令禁用后：

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

问题似乎已经解决。在过去的两周里，我们一直在增加工作量的情况下运行，并且这个问题没有再次出现。系统的上下文和中断始终是原来的 1/10，平均系统时间也减少了。

不确定它是否适合每个人，但我将其发布在这里作为可能的原因，以防它可以帮助其他人解决类似问题。