Postgresql 9.6 通过 BTRFS。好主意还是坏主意？

Question

我正在准备一台 VM 机器（在 Proxmox 上运行）来在 Ubuntu 16.04 LTS 上运行 postgresql 9.6。这个 postgres 将用于处理一家小公司的 Jira/FisheEye/Confluence 数据库。通常我们同时有几个用户，所以我们不需要调整它以获得极端的性能/可扩展性。

嗯，情况是，我们在服务器上使用 BTRFS 来帮助我们处理在必要时向虚拟机添加额外空间的问题，此外我们还启用了 lzo 压缩。此外，我们使用 btrok 来处理 BTRFS 子卷到另一台机器的备份。

我怀疑使用 BTRFS 处理 postgresql 数据库文件是否是一个好主意，因为我们在需要扩展虚拟硬盘空间的情况下会非常有帮助，但我读到了有关 postgresql 性能比 BTRFS 差的信息（在特殊情况下） datacow 未被禁用。

有人有这种情况的经验吗？

Answer 1

一般答案：坏主意。您可以在此处阅读有关它的一些详细信息。长话短说，BTRFS 的 COW 机制会导致正常 OLTP 工作负载的性能不一致

更好的答案：在某些情况下我会使用它。为什么以及如何：

• 只有当您真正对文件系统施加压力并为该数据库中的文件系统运行非常繁重的工作时，您才能注意到真正的性能差异。对于 JIRA 和 Confluence 来说，在正常工作负载下不太可能发生这种情况（假设您不在拥有数千名开发人员等的公司工作），尤其是在您正确调整和配置其缓存的情况下。另外，考虑到您想要启用压缩，听起来 IO 性能并不是您主要关心的问题:)。
• 考虑到前面的要点，可管理性、与当前工具和环境的良好集成以及有关您正在使用的技术的现有知识绝对应该胜过这样一个事实：在更高的工作负载中，其他文件系统可以提供更好的性能。
• 我还会考虑适当调整所有内容以进行补偿：在闪存上运行，进行适当的数据对齐（物理 <-> 控制器 <-> 分区 <-> FS <-> DB），进行适当的 FS（BTRFS 需要比您抛出的更多维护） -in-and-forget-about-it ext4)，以及数据库维护和调整。

我希望它有帮助。

注意：用户建议可以为特定卷/文件夹的 BTRFS 禁用 COW，但我忽略了这一事实。确实，它可以被禁用，但如果你这样做了，为什么还要使用 BTRFS？- 因为您仍然可以在文件系统的其余部分和所有其他很酷的功能（如快照等）上使用 COW，而不会影响 virtualbox 和 postgres 的性能？当然，纯数据库服务器使用 BTRFS 并禁用 COW 是没有意义的。但对于通用机器/服务器？它允许您使用所有很酷的功能（RAID1，...）而不会影响性能。在我看来，这是双赢。