我正在准备一台虚拟机（在 Proxmox 上运行）以在 Ubuntu 16.04 LTS 上运行 postgresql 9.6。此 postgres 将用于为一家小公司处理 Jira/FisheEye/Confluence 数据库。通常我们同时有几个用户，因此我们不需要对其进行调整以实现极高的性能/可扩展性。
嗯，实际情况是我们在服务器上使用 BTRFS 来帮助我们处理在必要时向 VM 添加额外空间的问题，另外我们启用了 lzo 压缩。此外，我们使用 btrok 来处理将 BTRFS 子卷备份到另一台机器。
我怀疑使用 BTRFS 来处理 postgresql DB 文件是否是个好主意，因为在我们需要扩展虚拟硬盘空间的情况下这会非常有帮助，但我读到过有关 postgresql 在 BTRFS 上性能不佳的文章（特别是在未禁用 datacow 的情况下）。
有人遇到过这种情况吗？
答案1
一般答案：坏主意。你可以阅读一些关于它的详细信息这里简而言之，BTRFS 的 COW 机制将导致正常 OLTP 工作负载的性能不一致
更好的答案：在某些情况下我会使用它。为什么以及如何：
- 只有当您真正对文件系统施加压力并为该数据库中的 FS 运行非常繁重的工作时，您才能注意到真正的性能差异。对于 JIRA 和 Confluence 来说，在正常工作负载下不太可能发生这种情况（假设您不在拥有数千名开发人员等的公司工作），特别是如果您正确调整和配置它们的缓存。此外，考虑到您想要启用压缩，IO 性能似乎不是您的主要关注点 :)。
- 考虑到前面的要点，可管理性、与当前工具和环境的良好集成以及有关您正在使用的技术的现有知识绝对应该胜过这样一个事实：在更高的工作负载下，其他文件系统可以提供更好的性能。
- 我还会考虑适当调整一切以进行补偿：在闪存上运行，进行适当的数据对齐（物理<->控制器<->分区<->FS<->DB），执行适当的FS（BTRFS比你的抛弃并忘记的ext4需要更多的维护），以及DB的维护和调整。
我希望它有帮助。
笔记：有位用户建议可以针对特定卷/文件夹禁用 BTRFS 的 COW，但我忽略了这一点。确实可以禁用，但如果这样做，为什么还要使用 BTRFS？——因为您仍然可以在其余文件系统上使用 COW 以及所有其他很酷的功能（如快照等），而不会影响 virtualbox 和 postgres 的性能？当然，纯 DB 服务器使用 BTRFS 并禁用 COW 是没有意义的。但对于通用机器/服务器来说呢？它允许您使用所有很酷的功能（RAID1，...），而不会影响性能。所以在我看来这是双赢。
答案2
有用户建议可以针对特定卷/文件夹禁用 BTRFS 的 COW，但我不予理会。确实可以禁用，但如果你这么做了，为什么还要使用 BTRFS？
即使对特定文件/文件夹禁用 COW，它们仍然具有快照功能。拍摄快照后，下一次写入将是 COW，然后返回到就地写入。对于正在运行的数据库来说，这是一个非常简单的备份解决方案，只要您在 FS 不忙时执行此操作即可。当然，您仍然会丢失所有就地写入的校验和。