PostgreSQLでの挿入パフォーマンスに最適なファイルシステムは何ですか？

そこにいる誰かが、ファイルシステムとデータベースのパフォーマンスを実験または比較したことがあれば、私は興味があります。Linuxでは、postgresデータベースに最適なファイルシステムは何だと思います。また、どの設定（inodeなど）が理想的ですか？これは、データベース内のデータに基づいて大幅に異なる可能性がありますか？

一般的なファイルシステム/データベースのパフォーマンスに関連する質問を探している場合、この投稿には良い情報があります。

ただし、読み取りパフォーマンスではなく、挿入パフォーマンスに関するアドバイスをできるだけ多く取得したいと思います。すばらしい回答をありがとうございました！

Greg Smithによる「postgresql high performance」のコピーを購入します。それは素晴らしい本であり、2つ以上の章はディスクハードウェアとファイルシステムについてです。あなたは多くを学びます。

つまり、簡単な答えはありません。

しかし、私はサマライズしようとします：

• 何をしているのかがわかるまでext2を使用しないでください。
• ext3では、fsync呼び出しによるチェックポイントの急上昇に注意してください。113および82および79ページを参照してください
• ext4またはxfsを使用します
• 他のオプションがあります

しかし、実際にどのFSを使用するかを自問しているので、この本を読むべきです！

まず第一に、信頼性の高いファイルシステムが最初に必要であり、高速の1秒が必要です。これはいくつかのオプションを除外しています...

パフォーマンステストは、多くの場合、XFSが最高のパフォーマンスを提供することを示しています。ディスクが非常に近い状態に達すると、安定性の問題が発生しますが、それが発生しないことを監視する限り、パフォーマンスはわずかに向上します。

理論的には、pg_xlogディレクトリにジャーナリングファイルシステムは必要ありませんが、速度の違いは通常非常に小さいため、それだけの価値はありません。データディレクトリには、常にメタデータジャーナリングファイルシステムが必要です。

データベース管理システムは、データベースログを通じて独自のジャーナリングを実装するため、ジャーナリングされたファイルシステムにそのようなDBMSをインストールすると、2つのメカニズムによりパフォーマンスが低下します。

1. 冗長ジャーナリングにより、ディスクアクティビティの量が増加します

2. 物理ディスクレイアウトは断片化できます（ただし、一部のジャーナリングファイルシステムにはこれをクリーンアップするメカニズムがあります）。

3. 大量のディスクアクティビティによりジャーナルがいっぱいになり、偽の「ディスクフル」状態が発生する可能性があります。

数年前に、HP / UXボックス上のBaanインストールのLFSファイルシステムでこれが行われたインスタンスを見てきました。システムには永続的なパフォーマンスとデータ破損の問題があり、ファイルシステムがLFSでフォーマットされていると誰かが判断するまで診断されませんでした。

データベースファイルを保持するボリュームには、通常、少数の大きなファイルがあります。通常、DBMSサーバーには、1つのI / Oで読み取るブロック数を構成する設定があります。冗長なデータのキャッシュを最小限に抑えるため、大容量のトランザクション処理システムには小さい数値が適しています。データウェアハウスなど、大量の連続読み取りを行うシステムには、より大きな数値が適しています。可能であれば、ファイルシステムの割り当てブロックサイズを、DBMSが設定されているマルチブロック読み取りと同じサイズに調整します。

一部のデータベース管理システムは、未加工のディスクパーティションを処理できます。これにより、さまざまな程度のパフォーマンスの向上が得られますが、通常、大量のメモリを搭載した最新のシステムではそれほど向上しません。ファイルシステムメタデータをキャッシュするスペースが少ない古いシステムでは、ディスクI / Oの節約が非常に重要でした。rawパーティションはシステムの管理を難しくしますが、利用可能な最高のパフォーマンスを提供します。

RAID-5ボリュームは、RAID-10ボリュームよりも書き込みオーバーヘッドが大きくなるため、書き込みトラフィックの多いビジーなデータベースのパフォーマンスは、RAID-10のほうが優れています（多くの場合、はるかに優れています）。ログは、物理的に別個のディスクボリュームをデータに配置する必要があります。データベースが大きく、ほとんどが読み取り専用の場合（データウェアハウスなど）、ロードプロセスが過度に遅くならない場合、RAID-5ボリュームに配置することがあります。

コントローラーのライトバックキャッシュは、データが破損する可能性のあるいくつかの（合理的ではないが可能性のある）障害モードを作成することを犠牲にして、パフォーマンスを向上させることができます。これに対する最大のパフォーマンスの向上は、非常にランダムなアクセスロードです。これを行う場合は、ログを別のコントローラーに配置し、ログボリュームのライトバックキャッシュを無効にすることを検討してください。これにより、ログのデータの整合性が向上し、1つの障害でログとデータボリュームの両方を取り出すことができなくなります。これにより、バックアップから復元し、ログからロールフォワードできます。

私はそのような詳細なレポートをしましたが、それはフランス語のみです。フランス語を読んだり、自動翻訳ツールに満足している場合...方法論を再利用して自分で実行できます。

エグゼクティブサマリー：pgbenchを使用しました。Linux I / Oスケジューラーは、パフォーマンスとファイルシステムの重要性がほとんどありません。そのため、急いでいる場合は、デフォルトを選択してください。JFSを選択しました。

ファイルシステムは問題の一部にすぎません。IOスケジューラーを変更することにより、パフォーマンスを大幅に向上させることができます。幸いなことに、これはIOスケジューラーをその場で変更できるため、テストは非常に簡単です。典型的な負荷の下で数日間それぞれを試してみて、どれが最高のパフォーマンスを発揮するかを確認することをお勧めします。

数か月前にいくつかのテストを行いました。

50個のスレッドを作成する小さなテストプログラムがあり、すべてのスレッドが同じテーブルに1000（または10000）行を挿入しました。

• EXT3上のデータベースと4ディスクRAID5では、50秒かかりました。
• ramdisk上のテーブル（テーブルスペースを使用）では、まだ50秒かかりました。速くなかった理由は、すべてが同じRAID 5にあるpg_xlogディレクトリに記録されるためです。
• pg_xlogを4ディスクRAID0（ストライプ）に移動し、同じプログラムを40秒で実行しました。
• テストのために、pg_xlogをramdiskに移動し、その他すべてをEXT3 4ディスクRAIDに配置しました。プログラムは5秒未満で終了しました。

しかし、ソフトウェアramdiskにpg___xlogを持つことはオプションではありません。pg_xlogディレクトリの内容を失うと、postgresは起動しません。（ただし、バッテリバックアップを備えたハードウェアRAMディスクが存在する可能性があります。）

私見：データベースファイルには、最も使いやすいファイルシステムを使用してください。pg_xlog（シンボリックリンク付き、ドキュメントを参照）を最速のデバイスに移動します。

FreeBSDを微調整すると、他のOSとは対照的に、もう少しパフォーマンスが向上することを思い出したようです。この情報は時代遅れであり、おそらく最初の神話であると確信していますが。ただし、それでも試してみることができます。カーネル設定については、次のガイドラインを参照してください：http : //developer.postgresql.org/pgdocs/postgres/kernel-resources.html