在 PostgreSQL 上插入性能最好的文件系统是什么？

Question

我很好奇是否有人做过文件系统和数据库性能之间的实验或比较。在 Linux 上，我想知道什么是 postgres 数据库的最佳文件系统。此外，什么设置（inode 等）最适合它？这是否会根据数据库中的数据而有很大不同？

如果你正在寻找与一般文件系统/数据库性能相关的问题，这个帖子有一些很好的信息。

不过，我希望得到尽可能多的建议插入性能与读取性能相反。感谢所有出色的回答！

Answer 1

购买一本 Greg Smith 的《postgresql high performance》。这是一本很棒的书，其中有两章或更多章节是关于磁盘硬件和文件系统的。您将学到很多东西。

简而言之：没有简短的答案。

但我会尝试总结一下：

• 在您清楚自己在做什么之前，请不要使用 ext2。
• 对于 ext3，请注意由于 fsync 调用而导致的检查点峰值，请参阅第 113 页和第 82 页和第 79 页
• 使用 ext4 或 xfs
• 还有其他选择

但是，当您确实在问自己要使用什么 FS 时，您应该阅读这本书！

Answer 2

首先，您需要一个可靠的文件系统，其次是快速的文件系统。这就排除了一些选择...

性能测试表明，XFS 通常能提供最佳性能。一旦达到磁盘接近满的情况，它就会出现一些稳定性问题，但只要您监控这种情况不会发生，它就会为您提供略微更好的性能。

理论上，您不需要为 pg_xlog 目录使用日志文件系统，但速度差异通常很小，因此不值得。对于数据目录，您确实应该始终使用元数据日志文件系统。

Answer 3

数据库管理系统通过数据库日志实现自己的日志记录，因此在日志文件系统上安装这样的 DBMS 会通过两种机制降低性能：

1. 冗余日志增加了磁盘活动量

2. 物理磁盘布局可能会出现碎片（尽管某些日志文件系统确实有清理碎片的机制）。

3. 大量的磁盘活动会填满日志，从而导致虚假的“磁盘已满”情况。

几年前我曾见过一个实例，在 HP/UX 机器上的 Baan 安装中，LFS 文件系统上出现了这种情况。该系统一直存在性能和数据损坏问题，直到有人发现文件系统是用 LFS 格式化的，才得以诊断。

保存数据库文件的卷通常包含少量大型文件。DBMS 服务器通常会有一个设置，用于配置在单个 I/O 中读取的块数。较小的数字适合高容量事务处理系统，因为它们可以最大限度地减少冗余数据的缓存。较大的数字适合执行大量连续读取的数据仓库等系统。如果可能，请将文件系统分配块大小调整为与 DBMS 设置的多块读取大小相同。

一些数据库管理系统可以使用原始磁盘分区。这会带来不同程度的性能提升，但在具有大量内存的现代系统上，这种提升通常较小。在用于缓存文件系统元数据的空间较少的旧系统上，磁盘 I/O 的节省相当可观。原始分区使系统更难管理，但可提供最佳性能。

RAID-5 卷比 RAID-10 卷产生更多的写入开销，因此，对于写入流量很大的繁忙数据库，在 RAID-10 上的性能会更好（通常好很多）。日志应放在与数据物理上分开的磁盘卷中。如果您的数据库很大且大部分都是只读的（例如数据仓库），则可能有必要将其放在 RAID-5 卷上，前提是这不会过度减慢加载过程。

控制器上的写回缓存可以为您带来性能提升，但代价​​是创建一些（可能性不大但有可能）的故障模式，在这些故障模式下数据可能会损坏。这种做法的最大性能提升是在高度随机访问负载下。如果您想这样做，请考虑将日志放在单独的控制器上，并禁用日志卷上的写回缓存。这样，日志将具有更好的数据完整性，并且单个故障不会同时损坏日志和数据卷。这允许您从备份中恢复并从日志中向前滚动。

Answer 4

文件系统只是问题的一部分。您可以通过更改 IO 调度程序来显著提高性能。幸运的是，这很容易测试，因为您可以动态更改 IO 调度程序。我建议在典型负载下试用每种调度程序几天，看看哪种调度程序性能最佳。