MySQL (InnoDB) 的最佳 Linux 文件系统是什么？

Question

我试图用 MySQL InnoDB 寻找各种文件系统性能的基准，但找不到。

我的数据库工作负载是典型的基于 Web 的 OLTP，大约 90% 读取，10% 写入。随机IO。

在 ext3、ext4、xfs、jfs、Reiserfs、Reiser4 等流行的文件系统中，您认为哪个最适合 MySQL？

Answer 1

您对数据的重视程度如何？

说真的，每个文件系统都有自己的权衡。在我更进一步之前，我是 XFS 和 Reiser 的忠实粉丝，尽管我经常运行 Ext3。所以这里没有真正的文件系统偏见，只是让你知道......

如果文件系统对您来说只不过是一个容器，那么请选择为您提供最佳访问时间的任何东西。

如果数据具有任何重要价值，您将希望避免 XFS。为什么？因为如果它不能恢复被记录的文件的一部分，它会将块清零并使数据不可恢复。此问题已在 Linux 内核 2.6.22 中修复。

ReiserFS 是一个很棒的文件系统，前提是它永远不会严重崩溃。日志恢复工作正常，但是如果由于某种原因您丢失了分区信息，或者文件系统的核心块被吹走，如果磁盘上有多个 ReiserFS 分区，您可能会遇到麻烦 - 因为恢复机制基本上扫描整个磁盘，一个扇区一个扇区，寻找它“认为”是文件系统的开始。如果您有三个带有 ReiserFS 的分区，但只有一个被炸毁，您可以想象这将导致的混乱，因为恢复过程将来自其他两个系统的 Frankenstein 混乱拼接在一起......

Ext3 是“慢”，在“我有 32,000 个文件，需要时间才能找到它们都在运行ls”有点像。如果您要在各处拥有数以千计的小型临时表，您会感到有点悲痛。较新的版本现在包含一个索引选项，可以显着减少目录遍历，但仍然很痛苦。

我从未使用过 JFS。我只能评论说，我读过的每一篇评论都是“可靠的，但不是街区中最快的孩子”。这可能值得调查。

缺点说完了，再来看看优点：

XFS：

• 巨大的文件尖叫，快速的恢复时间
• 非常快速的目录搜索
• 用于冻结和解冻文件系统以进行转储的原语

ReiserFS：

• 高度优化的小文件访问
• 将几个小文件打包成相同的块，节省文件系统空间
• 快速恢复，可媲美 XFS 恢复时间

分机3：

• 久经考验，基于经过良好测试的 Ext2 代码
• 周围有很多工具可以使用它
• 可以在紧要关头重新安装为 Ext2 以进行恢复
• 可以收缩和扩展（其他文件系统只能扩展）
• 最新版本可以“实时”扩展（如果你有胆量的话）

所以你看，每个人都有自己的怪癖。问题是，哪个对你来说最不古怪？

Answer 2

值得注意的是，您可以在没有文件系统的情况下运行 InnoDB，并在没有文件系统开销的情况下提高性能。我不确定我会推荐它，但我以前用过它没有问题。

InnoDB 原始设备

此外，如果您以 90% 的读取和 10% 的写入运行，除非您需要 InnoDB 的事务处理能力，否则您可能会考虑移植到 MyISAM 以获得更好的读取性能。

Answer 3

这里的答案已被严重弃用，需要更新，因为这将出现在 google 结果中。

对于生产环境，XFS。每次。XFS 是日志记录和非阻塞的。确保在生产中使用 InnoDB 的现代（2011/2012）MySQL 数据库具有以下变量：

innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT

不要使用 EXT3 甚至 EXT4。总有一天 BTRFS 会到达那里。

EXT3，也许是 EXT4，锁定在 inode 级别，不聪明！

来源： - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - Sasha Pachev 的了解 MySQL 内部 - https://www.facebook.com/note.php？ note_id=10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - 一些摆动套件，反复试验。

编辑：更新。EXT4 似乎在 2013 年年中表现不错！BTRFS 仍然不是一个好的选择。并且 RHEL 很可能使 XFS 成为新的默认文件系统。同样，不要使用 EXT3。

Answer 4

简短版本是我在文件系统上看到的最接近 MySQL 的建议是 XFS，但是 ext3 应该也可以，ext4 有望成为一个不错的改进，但它仍然不是很稳定，尽管它应该在年底。

如果您正在运行集群文件系统 CXFS、OCFS2 和 GFS 应该都可以。

我强烈警告不要使用任何 Reiser 衍生产品和 JFS，尽管它曾经被广泛部署的 XFS 和 ext4 击败。

Answer 5

不太可能有太大的不同。使用您的发行版作为默认值，前提是它足够了。

花你的精力调整其他事情 - 获得足够的内存 - 获得一个不会糟糕的突袭控制器 - 并修复应用程序对数据库的蹩脚（ab）使用（注意：在大多数情况下，这是主要的罪魁祸首，它尚未已完成）。

但是，请仔细考虑您放置 mysql tmpdir 的文件系统；这将影响性能，尤其是执行基于磁盘的 filesort() 的查询（有关更多详细信息，请参阅 EXPLAIN）。

我认为支持延迟分配的文件系统在这里真的很方便，因为当有足够的内存将它们保存在缓存中时，您可以完全避免对短期文件进行 IO。例如，XFS 根本不需要编写在分配之前被删除和关闭的文件。

当然，从性能角度来看，将 tmpdir 放在 tmpfs 上是有吸引力的，但会导致空间耗尽和查询失败的风险，否则会成功（尽管使用了磁盘临时文件）失败。

Answer 6

我没有找到任何关于在各种文件系统上运行的 MySQL 的基准“综述”的最新文章。鉴于您描述的工作量，我怀疑文件级碎片是否会成为一个大问题。没有正式的基准测试，我不能说任何你应该认为具有权威性的东西，但我的直觉说你上面提到的每个文件系统都将在大致相同的范围内执行（即所有性能数字的数量级都相同） .

数据库确实在运行，因为文件系统只是管理存储引擎正在访问的大范围。

尽管如此，对所有这些文件系统进行性能综述还是很有趣的。（不过，我对 MySQL 几乎没有热情，所以我不打算进行。对 Postgres、OTOH 进行基准测试可能会很有趣……）