BTRFSを介したPostgresql9.6。良いか悪いか？
Ubuntu 16.04LTS上でpostgresql9.6を実行するためにVMマシン（onver Proxmoxを実行）を準備しています。このpostgresは、小規模企業のJira/FisherEye/Confluenceデータベースを処理するために使用されます。 。通常、私たちは同時に数人のユーザーであるため、極端なパフォーマンス/拡張性のために調整する必要はありません。
必要に応じてVM）にスペースを追加する問題を処理するために、サーバーでBTRFSを使用している場合があります。さらに、lzo圧縮を有効にします。別のマシンへのBTRFSサブボリュームのバックアップを処理するbtrok。
仮想ハードディスク領域を拡張する必要がある場合に非常に役立つため、BTRFSを使用してpostgresql DBファイルを処理するのが良い考えかどうかは疑問ですが、BTRFSでのpostgresqlのパフォーマンスの低下について読みました（特別な場合datacowは無効になっていません。
誰もがこの状況の経験がありますか？
一般的な答え：悪い考え。あなたはそれについてのいくつかの詳細を読むことができます ここ 。簡単に言うと、BTRFSのCOWメカニズムにより、通常のOLTPワークロードでパフォーマンスの不整合が発生します。
より良い答え：特定の場合に私はそれを使用します。理由と方法：
- 実際にファイルシステムに負荷をかけ、そのDBでFS）に対して非常に重い作業を実行した場合にのみ、実際のパフォーマンスの違いに気付くことができます。特に、キャッシュを適切に調整および構成している場合は、何千人もの開発者がいる会社では機能しません。また、圧縮を有効にすることを考えると、IOパフォーマンスはあなたの主な関心事:)。
- 前の箇条書き、管理性、現在のツールと環境への適切な統合、および使用しているテクノロジーに関する既存の知識を考慮すると、はるかに高いワークロードでは、他のファイルシステムがより優れたパフォーマンスを提供するという事実よりも間違いなく優先されます。
- また、すべてを適切に調整して補正することも検討します。フラッシュメモリで実行し、適切なデータアライメントを実行します（物理<->コントローラー<->パーティショニング<-> FS <-> DB）、適切に実行します） FS（BTRFSは、throw-in-and-forget-about-it ext4よりも多くのメンテナンスを必要とします）、およびDBのメンテナンスとチューニング。
お役に立てば幸いです。
注：ユーザーが特定のボリューム/フォルダーのBTRFSに対してCOWを無効にできることを提案しましたが、私はその事実を無視します。実際、無効にすることはできますが、無効にする場合でも、なぜBTRFSを使用するのでしょうか。 --virtualboxとpostgresのパフォーマンスに影響を与えることなく、ファイルシステムの残りの部分と他のすべての優れた機能（スナップショットなど）でCOWを引き続き使用できるためですか？確かに、純粋なDBサーバーがBTRFSを使用してCOWを無効にすることは意味がありません。しかし、汎用マシン/サーバーの場合はどうでしょうか。これにより、パフォーマンスを低下させることなく、すべての優れた機能（RAID1、...）を使用できます。だから私の目にはwin-win。
ユーザーは、特定のボリューム/フォルダーのBTRFSに対してCOWを無効にできると提案しましたが、私はその事実を無視します。確かに、無効にすることはできますが、無効にする場合でも、なぜBTRFSを使用するのでしょうか。
特定のファイル/フォルダーに対してCOWが無効になっている場合でも、スナップショット機能はあります。スナップショットが作成された後、次の書き込みはCOWになり、インプレース書き込みに戻ります。 FSがビジーでないときに実行すると、データベースを実行するための非常に簡単なバックアップソリューションです。もちろん、すべてのインプレース書き込みのチェックサムは失われます。