PostgreSQL pg_stat_activityはCOMMITを示します

最近、データベースサーバーを、4 xクアッドコアCPUと32GbのRAMを備えたアップグレードされたマシンに置き換えました。また、古いボックスを再利用して、ストリーミングレプリケーションのスレーブとして機能させました。どちらのボックスもCentOS 6.3とPostgreSQL 9.2を実行しています。Postgresは、各ボックスで実行されている唯一のものです。

この構成は約1か月ほど前から行われていましたが、トラフィックが増加し始めたときに突然、いくつかの問題が発生し始めました。私たちが見始めているのは、ときどき非常に高い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 x 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

— jcern
ソース

新しいボックスにはどのような種類のディスクがありますか？これは両方のノードで発生していますか、それとも片方だけですか？

— TrygveLaugstøl2013年

@trygvis-ディスクの仕様で質問を更新しました。マスターノードで問題が発生しています。私はスレーブを宣伝してそこにトラフィックを向けようとしなかったので、それが同じ状況下でも問題なのかどうかはわかりません。スレーブとして、マシンには問題が発生していないようです。

— jcern 2013年

このperfツールを使用して、システム全体のプロファイリングとPostgreSQLプロファイリングを行うことを検討してください。CPU使用率が発生している場所を確認します。ちなみに、2番目の書式はvmstatどうしようもないほど壊れており、1番目の列は正しく配置されていないため、読みにくくなっています。を追加することでcommit_delay改善されるかどうかをテストします。RAIDコントローラにバッテリバックアップ式ライトバックキャッシュがあるかどうかを確認し、ない場合は取得します。に多くの時間が費やされていiowaitますか？これは一部のレポートではCPU使用率のように見えますが、実際にはそうではありません。

— クレイグリンガー2013年

@CraigRingerコントローラーにはバッテリーバックアップ式書き込みキャッシュがあり、現在有効になっています。iostatからの待機は、1桁から2桁低いままでした。今後も、perfを使用してさらにプロファイリングを試みます。2番目のVMStatのフォーマットも修正しました。指摘していただきありがとうございます。

— jcern 2013年

さらなる診断といくつかのグーグルの後で、私たちは経験している同じ症状の多くを説明するこの記事に出くわしました。彼らの問題の根本的な原因（そして私たちが知ることができることから、私たちの問題も）は、Transparent Huge Pages実装に関連していました。

Transparent Huge Pagesこのコマンドで無効にした後：

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

問題は解決されたようです。過去2週間、増加したワークロードの下で実行しており、問題は再発していません。システムのコンテキストと割り込みは、一貫してそれらの1/10であり、平均システム時間も減少しています。

それが誰にとっても解決策であるかどうかはわかりませんが、他の誰かが同様の問題を解決するのに役立つ可能性がある場合に備えて、考えられる原因としてここに投稿します。

— jcern
ソース