PostgreSQLの挿入パフォーマンスに最適なファイルシステムは何ですか？
ファイルシステムとデータベースのパフォーマンスを実験したり比較したりしたことがあるかどうか、知りたいです。 Linuxでは、postgresデータベースに最適なファイルシステムは何でしょうか。また、どの設定（iノードなど）が理想的ですか？これは、データベース内のデータに基づいて大幅に異なる可能性があるものですか？
一般的なファイルシステム/データベースのパフォーマンスに関する質問を探している場合は、 この投稿 に役立つ情報があります。
ただし、読み取りのパフォーマンスではなく、insertのパフォーマンスについてできる限り多くのアドバイスを受けたいと思います。すばらしい回答をありがとう！
Greg Smithによる「postgresql high performance」のコピーを購入してください。それは素晴らしい本であり、2つ以上の章がディスクハードウェアとファイルシステムについてです。あなたはたくさん学びます。
つまり、簡単な答えはありません。
しかし、私は要約しようとします：
- 自分が何をしているかがわかるまで、ext2を使用しないでください。
- ext3では、fsync呼び出しによるチェックポイントスパイクに注意してください。113、82、79ページを参照してください。
- ext4またはxfsを使用する
- 他のオプションがあります
しかし、あなたが本当にFSを使用することを自問しているので、あなたは本を読むべきです！
まず第一に、あなたは最初に信頼できるファイルシステムを望み、そして速い1秒を望みます。いくつかのオプションを除外しています...
パフォーマンステストでは、多くの場合、XFSが最高のパフォーマンスを提供することが示されています。完全に近いディスクのシナリオに到達すると、いくつかの安定性の問題がありますが、それが起こらないことを監視する限り、パフォーマンスがわずかに向上します。
理論的には、pg_xlogディレクトリにジャーナリングファイルシステムは必要ありませんが、速度の違いは通常非常に小さいため、価値がありません。データディレクトリの場合、実際には常にメタデータジャーナリングファイルシステムが必要です。
データベース管理システムは、データベースログを通じて独自のジャーナリングを実装するため、そのようなDBMSをジャーナルファイルシステムにインストールすると、次の2つのメカニズムによってパフォーマンスが低下します。
冗長ジャーナリングにより、ディスクアクティビティの量が増加します
物理ディスクレイアウトは断片化できます（ただし、一部のジャーナリングファイルシステムには、これをクリーンアップするメカニズムがあります）。
大量のディスクアクティビティによってジャーナルがいっぱいになり、偽の「ディスクフル」状態が発生する可能性があります。
HP/UXボックス上のBaanインストールのLFSファイルシステムでこれが行われた例を数年前に見ました。システムには永続的なパフォーマンスとデータ破損の問題があり、ファイルシステムがLFSでフォーマットされていることを誰かが解決するまで診断されませんでした。
通常、データベースファイルを保持するボリュームには、少数の大きなファイルがあります。通常、DBMSサーバーには、1つのI/Oで読み取るブロック数を構成する設定があります。冗長なデータのキャッシュを最小限に抑えるため、大量のトランザクション処理システムには小さい数が適しています。大きな値は、多くの逐次読み取りを行ったデータウェアハウスなどのシステムに適しています。可能であれば、DBMSが設定されているマルチブロック読み取りと同じサイズになるようにファイルシステムアロケーションブロックサイズを調整します。
一部のデータベース管理システムは、RAWディスクパーティションで機能します。これにより、さまざまな程度のパフォーマンス向上が得られますが、通常、大量のメモリを備えた最新のシステムではそれほどではありません。ファイルシステムメタデータをキャッシュするスペースが少ない古いシステムでは、ディスクI/Oの節約が非常に重要でした。 rawパーティションはシステムの管理を難しくしますが、最高のパフォーマンスを提供します。
RAID-5ボリュームは、RAID-10ボリュームよりも書き込みオーバーヘッドが多くなるため、書き込みトラフィックが多いビジーなデータベースは、RAID-10でパフォーマンスが向上します（多くの場合、パフォーマンスが大幅に向上します）。ログは、物理的に別個のディスクボリュームをデータに配置する必要があります。データベースが大きく、ほとんどが読み取り専用の場合（データウェアハウスなど）、ロードプロセスが過度に遅くならない場合、データベースをRAID-5ボリュームに配置することがあります。
コントローラーのライトバックキャッシュは、データが破損する可能性のあるいくつかの（かなり可能性は低いですが、可能性のある）障害モードを作成する代わりに、パフォーマンスを向上させます。このための最大のパフォーマンスの勝利は、非常にランダムアクセスの負荷です。これを行う場合は、ログを別のコントローラーに配置し、ログボリュームのライトバックキャッシュを無効にすることを検討してください。これにより、ログのデータ整合性が向上し、1つの障害でログとデータボリュームの両方を取り出すことができなくなります。これにより、バックアップから復元し、ログからロールフォワードすることができます。
私はそのような詳細なレポートをしましたが、それは フランス語のみ です。フランス語を読んだり、自動翻訳ツールに満足している場合...方法論を再利用して、自分で実行できます。
エグゼクティブサマリー：pgbenchを使用しました。 Linux I/Oスケジューラは、パフォーマンスとファイルシステムの重要性がほとんどありません。したがって、急いでいる場合は、デフォルトを選択してください。 JFSを選びました。
私は数ヶ月前にいくつかのテストを行いました：
私は、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を（シンボリックリンクを使用して、ドキュメントを参照してください）使用可能な最速のデバイスに移動します。
ファイルシステムは問題の一部にすぎません。 IOスケジューラーを変更することで、パフォーマンスを大幅に向上させることができます。幸い、IOスケジューラーをオンザフライで変更できるため、これは非常に簡単にテストできます。私はd典型的な負荷をかけた状態で数日間試してみて、どれが最高のパフォーマンスを発揮するかを確認してください。
FreeBSDを微調整すると、他のOSに比べてパフォーマンスが少し向上することを思い出しました。私はこの情報が時代遅れであり、おそらくそもそも神話であることを確信しています。ただし、それでも試すことができます。カーネルの設定については、次のガイドラインを参照してください。 http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html