書き込みパフォーマンスのためのPostgreSQLの構成

PostgreSQLサーバーの1つは、一定のデータストリームを受信する複数の（1〜3）データベースをホストしています。データは特に構造化されておらず、現在の時刻とその特定の瞬間のさまざまな観測データになります。データレートはかなり高いです。あるデータベースでは1日に約1ギガバイト、別のデータベースでは約10分の1になります。この率が上がるとは思わない。読み取りパフォーマンスは、はるかに低い優先度であり、現在許容されています。

ログにこのメッセージがあります：

LOG:  checkpoints are occurring too frequently (15 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

現在、この値は16に設定されていpgtuneます。

書き込みパフォーマンスを改善するために考慮すべき設定は何ですか？私は可能な限り安全に保つことを好むでしょう。入ってくるデータの量を考えると、データの大部分が無傷である限り、障害で最近のデータを失うことを受け入れることができます。

編集：今のところPostgreSQL 9.0を使用していますが、9.1にアップグレードする予定です。ハードウェアの詳細は掲載していませんが、その重要性は認識していますが、最終的には非常に多様なハードウェアを持つ複数のマシンでこの最適化を行う必要があります。ハードウェアが答えに不可欠な場合は、一般的な情報を教えてください。異なるハードウェア構成のマシンに答えを適用できます。

1日に1ギガバイトの書き込み負荷はそれほど大きくありません。1日を通して広がり、1秒あたり約50kバイトになります。遅いUSBサムドライブでそれを処理できます。私はそれがより破裂していると仮定しています。a_horse_with_no_nameが示唆するように、チェックポイントセグメントを増やします。100かそこらは異常ではありません。

次にcheckpoint_timeout、1時間に増やし、checkpoint_completion_target1.0（100％）に近い値に増やすことを検討します。完了ターゲットは、チェックポイントを実行する前にx％が完了するようにバックグラウンドでどのくらい積極的に書き込むかをPostgreSQLに指示します。

通常、100％に設定しない理由は、同じブロックに複数回書き込むのが非常に一般的であり、WALのメインストアへの書き込みを遅らせることにより、同じブロックが理由もなく2回書き込まれるのを防ぐためです。

タイムアウトが発生する前に同じブロックに複数回書き込む可能性が低い場合、つまり、挿入するだけで、かなり高い値に設定すると、0.9程度に上げるのが理にかなっています。最悪の事態は、他の方法で書くよりも少し頻繁に書くことですが、チェックポイントへの影響は大幅に減少します。

非常に「書き込みが重い」システムでは、ピークアクティビティ中にWALを書き込むことができるレートによって制限される可能性があります。

「障害で最近のデータの損失を受け入れる」ことが本当にできる場合、同期コミットをオフにすることができます。

トランザクションの耐久性についての正確な確実性よりもパフォーマンスが重要な場合、有用な代替手段になります。

ハードウェアを変更できる場合は、書き込みを最適化するために次のいずれかを検討できます。

• RAID10 over RAID5
• たくさんのスピンドル（たとえば、3.5 "ではなく2.5"を意味する場合があります）
• SAS over SATA
• 10Kドライブを超える15K
• SSD

-編集

@Scott の優れた回答に対するコメント：「書き込みボリュームは実際にはほぼ完全に均一です」、および暗黙のデータレート「1秒あたり50キロバイト」に基づいて、データ損失のリスクがあることを行う必要があるとは思いません。おそらく、他の構成パラメーターのいくつかがどのように設定されているかを知ることが役立つでしょう。

また、コミットの頻度/サイズを確認することもできます。最近、1つのトランザクションで100万件を超えるレコードを更新しようとしていた問題に遭遇しました。OPで説明されているものと同様のログメッセージを受け取りましたが、トランザクションは数時間経っても完了できませんでした。書き込みをいくつかの小さなトランザクション（10,000レコード程度）に分割すると、必要な合計時間は約15分になりました。

起こったと思うのは、Postgresがログの書き込みに非常に多くの時間を費やし、checkpoint_timeoutが経過してから、レコードを大幅に保存できるようになったことです。その説明が当てはまるかどうかはわかりません。それでも警告は表示されますが、すべての書き込みは最終的に処理されます。ただし、データベースの再構成が必要な回避策ではなく、プログラムによる回避策が必要でした（そして見つかりました）。

http://www.postgresql.org/docs/9.3/static/wal-configuration.htmlも参照してください