Postgres 9.4 升级后的性能提升

Question

昨晚将我们的数据库从 9.3.5 升级到 9.4.1 后，服务器遇到了高 CPU 峰值。升级是通过 pg_dump 完成的。于是把数据库转成SQL，再导入9.4。

在 CPU 峰值期间，日志中有很多这样的消息：

process X still waiting for ExclusiveLock on extension of relation Y of database Z 
after 1036.234 ms

和：

process X acquired ExclusiveLock on extension of relation Y of database Z
after 2788.050 ms

看起来可疑的是，有时在完全相同的毫秒内有几个完全相同的关系号的“获取”消息。

为什么 Postgres 会在同一毫秒内将一个表增长两次？它可能是一个具有高填充因子的索引吗？

欢迎任何有关如何解决此问题的建议。

PS 我也在Postgres 邮件列表上问过这个问题，如果不行，请告诉我。

Answer 1

该问题与称为透明大页 (THP) 的内核功能有关。您可以使用以下方法诊断此问题perf top：

 59.73%       postmaster  [kernel.kallsyms]      [k] compaction_alloc
  1.31%       postmaster  [kernel.kallsyms]      [k] _spin_lock
  0.94%       postmaster  [kernel.kallsyms]      [k] __reset_isolation_suitable
  0.78%       postmaster  [kernel.kallsyms]      [k] compact_zone
  0.67%       postmaster  [kernel.kallsyms]      [k] get_pageblock_flags_group
  0.64%       postmaster  [kernel.kallsyms]      [k] copy_page_c
  0.48%           :13410  [kernel.kallsyms]      [k] compaction_alloc
  0.45%           :13465  [kernel.kallsyms]      [k] compaction_alloc
  0.45%       postmaster  [kernel.kallsyms]      [k] clear_page_c
  0.44%       postmaster  postgres               [.] hash_search_with_hash_value
  0.41%           :13324  [kernel.kallsyms]      [k] compaction_alloc
  0.40%           :13561  [kernel.kallsyms]      [k] compaction_alloc

该compaction_alloc函数指出了一个问题。您可以通过以下方式关闭 THP：

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

9.4 之前的 Postgres 版本并不特别要求大页面，但可以使用always.

以下是 RedHat 不鼓励在数据库工作负载中使用 THP 的链接。