PostgreSQL pg_stat_activity显示COMMIT

最近，我们用具有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

postgresql

— 杰森
source

新盒子有什么样的磁盘？这是在两个节点上还是仅在其中一个节点上发生？

— TrygveLaugstøl13年

@trygvis-我用磁盘规格更新了问题。该问题正在主节点上发生。我没有尝试提升从站并直接将流量引向它，因此我不确定在相同情况下它是否也是一个问题。作为奴隶，机器似乎没有任何问题。

— jcern

考虑使用该perf工具进行系统范围内的分析和PostgreSQL分析。查看发生CPU使用情况的位置。顺便说一句，您的第2 vmstat列的格式被毫无希望地弄乱了，第1列的列未对齐，因此很难阅读。测试以查看是否添加了commit_delay改进项。检查您的RAID控制器是否具有电池供电的回写缓存，如果没有，则获取一个。花了很多时间iowait吗？在某些报告中，这似乎是CPU使用率，但实际上并非如此。

— Craig Ringer

@CraigRinger控制器确实具有备用电池的写缓存，并且当前已启用。iostat的等待数保持在两位数到低两位数之间。我们将继续尝试对perf进行更多分析。我还修复了第二个VMStat的格式，谢谢您指出这一点。

— jcern 2013年

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

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

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

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

不确定是否适合所有人，但如果有可能帮助其他人解决类似问题，我可能会在此发布。

— 杰森
source