主页 / server / 问题 / 29193
Accepted
Continuation
Asked: 2009-06-21 11:06:00 +0800 CST

MySQL（InnoDB）最好的 Linux 文件系统是什么？

  • 772

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

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

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

linux mysql filesystems database benchmark

7 个回答

  1. Best Answer

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

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

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

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

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

    Ext3 是“慢”的，在“我有 32,000 个文件并且需要时间才能找到它们都在运行ls”的方式。如果你要到处都有成千上万的小临时表，你会有点悲伤。较新的版本现在包括一个索引选项，可以显着减少目录遍历，但它仍然会很痛苦。

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

    缺点说完了，让我们来看看优点：

    XFS：

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

    ReiserFS：

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

    分机3：

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

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

    • 45

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

    InnoDB 原始设备

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

    • 13

  3. 这里的答案已被严重弃用，需要更新，因为这将出现在谷歌搜索结果中。

    对于生产环境，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。

    • 11

  4. 简短的版本是我见过 MySQL 在文件系统上提出的最接近建议的是 XFS，但是 ext3 也应该没问题，ext4 承诺会是一个很好的改进，但它仍然不是很稳定，虽然它应该在年底。

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

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

    • 9

  5. 这不太可能有太大的不同。只要足够，就可以使用您的发行版默认使用的任何内容。

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

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

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

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

    • 6

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

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

    尽管如此，对所有这些文件系统进行性能汇总还是很有趣的。（不过，我对 MySQL 几乎没有热情，所以我不打算进行它。基准 Postgres，OTOH，可能很有趣......）

    • 5

  7. 恕我直言，Linux 可用的值得注意的 FS 是：

    XFS（读取速度差）以占用系统资源少而著称，处理大文件速度快，但处理大量小文件却很差。

    ReiserFS（写入速度慢）对系统资源不太友好，但在处理大量小文件时表现非常好。

    EXT3 介于两者之间，在所有领域都可以接受（它被认为是默认的linux FS 的原因）。

    我自己还没有使用过 EXT4 而不是 ReiserFS4，但我查看了一些基准测试，ReiserFS 似乎在读取速度方面具有最佳性能，你说这对你来说是最重要的。

    看看这个：ReserFS4 X Ext4 X Ext3

    我会推荐 Ext3，因为它的稳定性、安全性和成熟度，但如果读取速度对你来说是最重要的，你应该考虑 ReiserFS。

    请记住，在选择 FS 之前，您还应该考虑 CPU 使用率、稳定性、安全性等。

    当然，在您的特定环境中进行试点、测试和基准测试始终是判断什么最适合您的最佳方式。

    PS：我会发布更多基准，但我不能发布多个链接。

    • 3

相关问题