まず、常に最新バージョンのPostgreSQLを使用します。パフォーマンスの向上は常に行われているため、古いバージョンをチューニングしている場合は、おそらく時間を無駄にしているでしょう。たとえば、PostgreSQL 9.2は、TRUNCATEの速度を大幅に向上させます。 もちろん、インデックスのみのスキャンを追加します。マイナーリリースでも常に従う必要があります。バージョンポリシーを参照してください。
禁止事項
しない 表領域をRAMディスクまたはその他の非耐久性ストレージに配置します。
表領域を失うと、データベース全体が損傷し、大きな作業なしでは使用できなくなる可能性があります。 UNLOGGEDを使用する場合と比較して、これにはほとんど利点がありません。 テーブルととにかくキャッシュ用のRAMがたくさんあります。
本当にRAMディスクベースのシステムが必要な場合は、initdb initdbによるRAMディスク上のまったく新しいクラスター ramdiskに新しいPostgreSQLインスタンスを作成することで、完全に使い捨てのPostgreSQLインスタンスを作成できます。
PostgreSQLサーバーの構成
テストするときは、永続的ではないがより高速な操作のためにサーバーを構成できます。
これは、fsync=offの唯一の許容可能な使用法の1つです。 PostgreSQLでの設定。この設定により、PostgreSQLは、順序付けられた書き込みやその他の厄介なデータ（整合性保護やクラッシュセーフ）を気にせず、電源が切れたりOSがクラッシュしたりした場合にデータを完全に破棄することができます。
言うまでもなく、fsync=offを有効にしないでください。 Pgをデータの一時データベースとして使用している場合を除き、本番環境では他の場所から再生成できます。 fsyncをオフにする場合に限り、full_page_writesもオフにできます。 それはもはや何の役にも立たないので、オフにします。 fsync=offに注意してください およびfull_page_writes クラスターで適用 レベルなので、すべてに影響します PostgreSQLインスタンスのデータベース。
本番環境で使用する場合は、synchronous_commit=offを使用できます。 commit_delayを設定します 、fsync=offと同じメリットの多くが得られるため 巨大なデータ破壊のリスクなし。非同期コミットを有効にすると、最近のデータが失われる小さなウィンドウがありますが、それだけです。
DDLを少し変更するオプションがある場合は、UNLOGGEDを使用することもできます。 Pg 9.1以降のテーブルは、WALロギングを完全に回避し、サーバーがクラッシュした場合にテーブルが消去されることを犠牲にして、実際の速度を向上させます。すべてのテーブルをログに記録しないようにする構成オプションはありません。CREATE TABLE中に設定する必要があります。 。これは、テストに適しているだけでなく、データベースに生成されたデータや重要でないデータでいっぱいのテーブルがあり、それ以外の場合は安全である必要があるものが含まれている場合に便利です。
ログをチェックして、チェックポイントが多すぎるという警告が表示されていないかどうかを確認してください。もしそうなら、checkpoint_segmentsを増やす必要があります。また、checkpoint_completion_targetを調整して、書き込みをスムーズにすることもできます。
shared_buffersを調整します あなたのワークロードに合うように。これはOSに依存し、マシンで他に何が起こっているかに依存し、試行錯誤が必要です。デフォルトは非常に保守的です。 shared_buffersを増やす場合は、OSの最大共有メモリ制限を増やす必要がある場合があります PostgreSQL9.2以下。 9.3以降では、それを回避するために共有メモリの使用方法が変更されました。
多くの作業を行う接続をいくつか使用している場合は、work_memを増やしてください。 並べ替えなどで使用できるRAMを増やすため。work_memが高すぎることに注意してください。 設定は、接続ごとではなくソートごとであるため、メモリ不足の問題を引き起こす可能性があります。そのため、1つのクエリに多数のネストされたソートを含めることができます。あなたは本当に work_memを増やす必要があります EXPLAINでディスクにソートがこぼれるのを見ることができる場合 またはlog_temp_filesでログに記録されます 設定（推奨）ですが、値を高くすると、Pgがよりスマートなプランを選択できる場合もあります。
ここで別のポスターが述べているように、可能であれば、xlogとメインテーブル/インデックスを別々のHDDに配置するのが賢明です。別々のパーティションはかなり無意味です、あなたは本当に別々のドライブが必要です。 fsync=offで実行している場合、この分離によるメリットははるかに少なくなります。 UNLOGGEDを使用している場合は、ほとんどありません。 テーブル。
最後に、クエリを調整します。 random_page_costを確認してください およびseq_page_cost システムのパフォーマンスを反映し、effective_cache_sizeを確認します 正しいなどです。EXPLAIN (BUFFERS, ANALYZE)を使用してください 個々のクエリプランを調べて、auto_explainをオンにします モジュールをオンにして、すべての遅いクエリを報告します。多くの場合、適切なインデックスを作成するか、コストパラメータを調整するだけで、クエリのパフォーマンスを劇的に向上させることができます。
AFAIKデータベース全体またはクラスター全体をUNLOGGEDとして設定する方法はありません 。そうすることができるのは面白いでしょう。 PostgreSQLメーリングリストで質問することを検討してください。
ホストOSのチューニング
オペレーティングシステムレベルで実行できるチューニングもいくつかあります。あなたがしたいと思うかもしれない主なことは、オペレーティングシステムにディスクへの書き込みを積極的にフラッシュしないように説得することです。なぜなら、それらがいつ/ディスクに到達するかは本当に気にしないからです。
Linuxでは、仮想メモリサブシステムのdirty_*を使用してこれを制御できます。 dirty_writeback_centisecsなどの設定 。
ライトバック設定の調整が緩すぎる場合の唯一の問題は、他のプログラムによるフラッシュにより、PostgreSQLの蓄積されたすべてのバッファーもフラッシュされ、すべてが書き込みをブロックしている間に大きなストールが発生する可能性があることです。別のファイルシステムでPostgreSQLを実行することでこれを軽減できる場合がありますが、一部のフラッシュはファイルシステムレベルではなくデバイスレベルまたはホスト全体レベルである可能性があるため、これに依存することはできません。
このチューニングでは、実際に設定を試して、ワークロードに最適なものを確認する必要があります。
新しいカーネルでは、vm.zone_reclaim_modeを確認することをお勧めします PostgreSQLがshared_buffersを管理する方法との相互作用により、NUMAシステム（最近のほとんどのシステム）で重大なパフォーマンスの問題が発生する可能性があるため、はゼロに設定されます。 。
クエリとワークロードの調整
これらは、コードの変更が必要なものです。彼らはあなたに合わないかもしれません。いくつかはあなたが適用できるかもしれないものです。
作業をより大きなトランザクションにバッチ処理していない場合は、開始します。小さなトランザクションの多くはコストがかかるため、可能で実用的な場合はいつでもバッチ処理する必要があります。非同期コミットを使用している場合、これはそれほど重要ではありませんが、それでも強くお勧めします。
可能な限り、一時テーブルを使用してください。これらはWALトラフィックを生成しないため、挿入と更新がはるかに高速になります。場合によっては、大量のデータを一時テーブルにまとめ、必要に応じて操作してから、INSERT INTO ... SELECT ...を実行する価値があります。 それをファイナルテーブルにコピーします。一時テーブルはセッションごとであることに注意してください。セッションが終了するか、接続が失われると、一時テーブルが消え、他の接続はセッションの一時テーブルの内容を見ることができなくなります。
PostgreSQL 9.1以降を使用している場合は、UNLOGGEDを使用できます。 セッション状態など、失う余裕のあるデータのテーブル。これらは異なるセッション間で表示され、接続間で保持されます。サーバーが不潔にシャットダウンすると切り捨てられるため、再作成できないものには使用できませんが、キャッシュ、マテリアライズドビュー、状態テーブルなどには最適です。
一般に、DELETE FROM blah;はしないでください。 。 TRUNCATE TABLE blah;を使用します 代わりは;テーブル内のすべての行をダンプする場合は、はるかに高速です。 1つのTRUNCATEで多くのテーブルを切り捨てます できれば電話してください。多くのTRUNCATESを実行している場合は、注意が必要です。 しかし、小さなテーブルを何度も何度も繰り返します。参照：Postgresqlの切り捨て速度
外部キーのインデックスがない場合は、DELETE これらの外部キーによって参照される主キーを含むものは、ひどく遅くなります。 DELETEを期待する場合は、必ずそのようなインデックスを作成してください。 参照されたテーブルから。 TRUNCATEにはインデックスは必要ありません 。
不要なインデックスを作成しないでください。各インデックスにはメンテナンスコストがかかります。非常に多くの高価な複数列のインデックスを維持するのではなく、最小限のインデックスセットを使用し、ビットマップインデックススキャンでそれらを組み合わせるようにしてください。インデックスが必要な場合は、最初にテーブルにデータを入力し、最後にインデックスを作成してみてください。
ハードウェア
データベース全体を保持するのに十分なRAMがあることは、それを管理できれば大きなメリットです。
十分なRAMがない場合は、ストレージが高速であるほど優れています。安価なSSDでさえ、回転する錆に大きな違いをもたらします。ただし、安価なSSDを本番環境で信頼しないでください。多くの場合、クラッシュセーフではなく、データを消費する可能性があります。
学習
Greg Smithの本、PostgreSQL 9.0 High Performanceは、やや古いバージョンを参照しているにもかかわらず、引き続き関連性があります。役立つ参考資料になるはずです。
PostgreSQLの一般的なメーリングリストに参加してフォローしてください。
読書：
- PostgreSQLサーバーの調整-PostgreSQLwiki
- データベース接続の数-PostgreSQLwiki