まず、常に最新バージョンのPostgreSQLを使用します。パフォーマンスは常に改善されるため、古いバージョンをチューニングする場合は、おそらく時間を無駄にしています。たとえば、PostgreSQL 9.2では速度が大幅に向上し、TRUNCATEもちろんインデックスのみのスキャンが追加されます。マイナーリリースであっても常に従う必要があります。バージョンポリシーをご覧ください。
しない
テーブルスペースをRAMdiskやその他の非永続ストレージに置かないでください。
テーブルスペースを失うと、データベース全体が損傷し、大きな作業を行わないと使用が困難になる可能性があります。UNLOGGEDとにかく、テーブルを使用してキャッシュ用に大量のRAMを用意する場合と比較して、これにはほとんど利点がありません。
RAMディスクベースのシステムが本当に必要な場合initdbは、RAMディスク上のまったく新しいクラスタをinitdbな場合は、ramdisk上の新しいPostgreSQLインスタンスを実行して、ramdiskすることで、完全に使い捨てのPostgreSQLインスタンスを作成できます。
PostgreSQLサーバーの設定
テストするときは、サーバーを非耐久性でより高速な動作に設定できます。
これはfsync=off、PostgreSQL の設定で受け入れられる唯一の使用方法の1つです。この設定は、順序付けされた書き込みやその他の厄介なデータ整合性保護やクラッシュセーフ機能に煩わされないように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_buffersPostgreSQL 9.2以下で増やす場合、OSの最大共有メモリ制限を増やす必要があるかもしれません。9.3以降では、共有メモリを使用してそれを回避する方法が変更されました。
多くの作業を行う接続を2、3だけ使用している場合は、値work_memを増やして、work_mem並べ替えなどに使用できるRAMを増やします。設定が高すぎると、並べ替えごとではないため、メモリ不足の問題が発生する可能性があることに注意してください。接続ごとなので、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モジュールをオンにしてすべての遅いクエリを報告します。多くの場合、適切なインデックスを作成するか、コストパラメータを調整するだけで、クエリのパフォーマンスを劇的に改善できます。
私の知る限り、データベースまたはクラスタ全体をとして設定する方法はありませんUNLOGGED。そうすることができたら面白いでしょう。PostgreSQLメーリングリストで質問することを検討してください。
ホストOSの調整
オペレーティングシステムレベルで実行できるチューニングもあります。あなたがしたいと思うかもしれない主なことは、ディスクへの書き込みをいつ行うかは本当に気にしないので、書き込みをディスクに積極的にフラッシュしないようにオペレーティングシステムを説得することです。
Linuxでは、これを仮想メモリサブシステムのdirty_*設定で制御できますdirty_writeback_centisecs。
ライトバック設定をあまりにも緩やかに調整することの唯一の問題は、他のプログラムによるフラッシュにより、すべてのPostgreSQLの累積バッファーもフラッシュされ、書き込みがすべてブロックされている間に大きなストールが発生する可能性があることです。別のファイルシステムでPostgreSQLを実行することでこれを軽減できる可能性がありますが、一部のフラッシュはファイルシステムレベルではなく、デバイスレベルまたはホスト全体のレベルであるため、それに依存することはできません。
このチューニングでは、実際にワークロードに最適なものを確認するために設定をいじる必要があります。
新しいカーネルでは、vm.zone_reclaim_modePostgreSQLの管理方法との相互作用により、NUMAシステム（最近のほとんどのシステム）で深刻なパフォーマンスの問題を引き起こす可能性があるため、これをゼロに設定することをお勧めしますshared_buffers。
クエリとワークロードのチューニング
これらはコードの変更を必要とするものです。彼らはあなたに合わないかもしれません。いくつかはあなたが適用できるかもしれないものです。
作業をより大きなトランザクションにバッチ処理しない場合は、開始します。小さなトランザクションがたくさんあるとコストがかかるので、可能で実用的な場合はいつでもバッチ処理する必要があります。非同期コミットを使用している場合、これはそれほど重要ではありませんが、それでも強くお勧めします。
可能な限り、一時テーブルを使用してください。WALトラフィックを生成しないため、挿入と更新の速度が大幅に向上します。大量のデータを一時テーブルに投入し、必要に応じて操作しINSERT INTO ... SELECT ...てから、ファイナルテーブルにコピーすることをお勧めします。一時テーブルはセッションごとであることに注意してください。セッションが終了するか、接続が失われると、一時テーブルは消え、他の接続はセッションの一時テーブルの内容を見ることができなくなります。
PostgreSQL 9.1以降を使用UNLOGGEDしている場合は、セッション状態など、失われる可能性のあるデータのテーブルを使用できます。これらは、さまざまなセッションにわたって表示され、接続間で保持されます。サーバーが不適切にシャットダウンした場合は切り捨てられるため、再作成できないものには使用できませんが、キャッシュ、マテリアライズドビュー、ステートテーブルなどには最適です。
一般的には、しないでくださいDELETE FROM blah;。TRUNCATE TABLE blah;代わりに使用してください。テーブル内のすべての行をダンプする方がはるかに高速です。TRUNCATE可能であれば、1回の呼び出しで多くのテーブルを切り捨てます。TRUNCATESただし、小さなテーブルを何度も何度も実行する場合は注意が必要です。参照：Postgresqlの切り捨て速度
外部キーにインデックスがない場合DELETE、それらの外部キーによって参照される主キーを含むは、恐ろしく遅くなります。DELETE参照されているテーブルから期待する場合は、必ずこのようなインデックスを作成してください。にはインデックスは必要ありませんTRUNCATE。
不要なインデックスを作成しないでください。各インデックスには保守コストがあります。インデックスの最小限のセットを使用し、ビットマップインデックススキャンでそれらを結合できるようにしてください。巨大で高価なマルチカラムインデックスを多く維持するのではなく、インデックスが必要な場合は、まずテーブルにデータを入力してから、最後にインデックスを作成してください。
ハードウェア
データベース全体を保持するのに十分なRAMがあれば、それを管理できれば大きな利益になります。
十分なRAMがない場合は、より高速なストレージでより良い結果を得ることができます。安価なSSDでも、回転する錆びとは大きく異なります。ただし、本番用の安価なSSDを信頼しないでください。クラッシュ安全ではないことが多く、データが破壊される可能性があります。
学習する
グレッグ・スミスの著書であるPostgreSQL 9.0 High Performanceは、やや古いバージョンについて言及しているにもかかわらず、依然として重要です。参考になるはずです。
PostgreSQL一般メーリングリストに参加して、フォローしてください。
読書：