大量のRAMに対するpostgresqlのチューニング

（ハードウェアの点で）2つの同一のサーバーがあり、どちらもWindows Server 2008 r2の標準インストールであり、最小限のソフトウェアがインストールされています（基本的には私のコードとjvmなどの必要なもの）。

1台のサーバーで、2台目のサーバーpostgresql 9.1でSQL Server 2005を実行しています。これら2台のサーバーでのパフォーマンスの違いは驚異的であり、上司への最初の「SQLサーバーライセンスの代金を支払う代わりにpostgresqlを使用しましょう」と後悔しています。同じコマンドで30秒と15分という違いを話しているのですが、これはこの1つのコマンドだけでなく、私が投げるクエリやコマンドでもあります。両方ともほぼ同じデータを持ち（レコードは異なる順序で挿入されました）、両方のデータベースはまったく同じ構造/インデックスなどを持っています。

しかし、それは単なるパフォーマンスチューニングの問題だと思います。実は、SQLサーバーはサーバー上で32ギガバイトすべてのRAMを使用していますが、postgreslは何も使用しておらず、ギグよりも確実に少ないのですが、実際には詳細に把握していません。

postgresqlで20ギガバイト以上のRAMを使用するにはどうすればよいですか？これらのサーバーはこのデータベース専用に構築されているため、データベースとサポートプロセスで使用されていないラムは無駄になります。

を介して初期化される調整可能な定数は多数ありますpostgres.conf。最も重要なものは次のとおりです。

• max_connections：同時セッションの数
• work_mem ：ハッシュテーブルなどの中間結果とソートに使用されるメモリの最大量
• shared_buffers 「ピン留めされた」バッファスペース専用のメモリ量。
• effective_cache_size OSのLRUバッファによって使用されると想定されるメモリの量。
• random_page_cost ：ディスクシークの相対コストの見積もり。

max_connections必要以上に高く設定しないでください。接続がアイドル状態でもリソースにコストがかかります。ほとんどの場合、接続は外部で待機するよりも内部で待機する方が時間がかかります。（並行性の代償で）経験則としては、「スピンドルの数+プロセッサの数+ X」という素晴らしい経験則があります。

work_memトリッキーです。これはすべてのサブクエリに適用できるため、5のクエリのHASHJOINSコストは5 *になりwork_memます。また、最悪のシナリオでは、複数のセッションがこの量を消費することも考えてください（これもmax_connections低く抑える理由です）。

shared_buffers（私見）過大評価されています。通常、利用可能なすべての「空き」メモリの約1/4 ... 1/2に設定することをお勧めしますが、私はそれを低く保ち、effective_cache_size利用可能なすべての「空き」メモリに設定する傾向があります。

random_page_costディスク上のシーク+読み取りのコストです。これは、1に相対的sequential_disk_costです。デフォルトの（4）random_page_costは、最新のマシンおよびネットワークストレージに対して高すぎる値に設定されており、通常は2〜1.xに下げることができます。SSDでは、シークはほぼ無料であるため、youldは1.0に設定します。

PostgreSQL構成の調整に役立つpgtuneの使用を検討してください。PgFoundryから：

pgtuneはwimpyのデフォルトのpostgresql.confを取得し、データベースサーバーを展開して、展開先のハードウェアと同じくらい強力にします

PostgreSQLのデフォルト設定は非常に保守的であり、このツールはこの正確な状況を支援することを目的としています。ドキュメントは簡単に読むことができ、ツールの使用は非常に簡単です。

pgtuneの正確な提案を使用する必要がないことに注意してください。設定を再生し、confファイルに加えられた変更を監視することで、PostgreSQLの設定と、手動で設定を調整する方法について理解を深めることができます。

すべてのクエリまたはコマンドがゆっくり実行されている場合、私はそれを疑います：

• 実行するクエリごとにデータベースに接続します。
• 何らかの認証方法を設定しましたが、これは機能せず、この特定の認証方法がタイムアウトするまでクエリを停止します。

次のようなクエリの実行にかかる時間を教えてくださいselect version()。インスタント（私のワークステーションでは0,16ms）でなければなりません。

すべてのクエリが非常に遅い場合、サーバーまたは何かで何かがひどく間違っています。私の経験では、各データベースには他のデータベースよりも優れている点がいくつかありますが、パフォーマンスに関してはpgsqlはmssqlサーバーと同じ領域に簡単にあります。

それでは、どのOSでpgsqlを実行していますか？どんなハードウェア？すでにどの設定を変更しましたか？データセットの大きさは？質の悪いクエリとExplain分析の出力の例は次のとおりです（次のようにクエリを実行します。

分析選択...クエリの残りをここで説明...;

出力をhttp://explain.depesz.com/に投稿し、リンクをここに投稿します。