我尝试寻找针对 MySQL InnoDB 的各种文件系统的性能的基准,但没有找到任何结果。
我的数据库工作负载是典型的基于 Web 的 OLTP,大约 90% 为读取,10% 为写入。随机 IO。
在流行的文件系统(如 ext3、ext4、xfs、jfs、Reiserfs、Reiser4 等)中,您认为哪一个最适合 MySQL?
答案1
您对数据的重视程度有多高?
说真的,每个文件系统都有自己的权衡。在我进一步讨论之前,我非常喜欢 XFS 和 Reiser,尽管我经常运行 Ext3。所以这里并没有真正的文件系统偏见,只是想让你知道……
如果文件系统对您来说只不过是一个容器,那么请选择能为您提供最佳访问时间的文件系统。
如果数据具有任何重要价值,您将需要避免使用 XFS。为什么?因为如果它无法恢复已记录的文件的一部分它将清零块并使数据无法恢复。这个问题是在 Linux 内核 2.6.22 中已修复。
ReiserFS 是一个很棒的文件系统,前提是它从不严重崩溃日志恢复工作正常,但如果由于某种原因你丢失了分区信息,或者文件系统的核心块被吹走了,你可能会陷入困境,如果磁盘上有多个 ReiserFS 分区 - 因为恢复机制基本上逐个扇区地扫描整个磁盘,寻找它“认为”的文件系统的起始位置。如果您有三个 ReiserFS 分区,但只有一个分区损坏,您可以想象这将造成多大的混乱,因为恢复过程会将其他两个系统的混乱拼凑在一起……
Ext3 很“慢”,就像“我有 32,000 个文件,要花一些时间才能找到它们ls
”一样。如果您到处都有数千个小型临时表,那么您会感到有些痛苦。较新的版本现在包含一个索引选项,可以大大减少目录遍历,但仍然很痛苦。
我从未使用过 JFS。我只能说,我读过的所有关于它的评论都是“可靠,但不是最快的”。它可能值得研究。
说完缺点,我们来看看优点:
XFS:
- 巨大的文件,快速的恢复时间
- 非常快速的目录搜索
- 用于冻结和解冻文件系统以进行转储的原语
ReiserFS:
- 高度优化的小文件访问
- 将多个小文件打包到相同的块中,节省文件系统空间
- 快速恢复,媲美 XFS 恢复时间
扩展 3:
- 经过实践检验,基于经过充分测试的 Ext2 代码
- 有很多工具可以使用它
- 紧急情况下可以重新挂载为 Ext2 以便恢复
- 可以两者皆可压缩并扩展(其他文件系统只能扩展)
- 最新版本可以“实时”扩展(如果你够大胆的话)
所以你看,每个人都有自己的怪癖。问题是,对你来说,哪一个最不怪癖?
答案2
可能还值得一提的是,您可以在没有文件系统的情况下运行 InnoDB,并在没有文件系统开销的情况下提高性能。我不确定我是否推荐它,但我以前用过它,没有问题。
此外,如果您以 90% 的读取和 10% 的写入运行,除非您需要 InnoDB 的事务能力,否则您可能需要考虑移植到 MyISAM 以获得更好的读取性能。
答案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/ - 一些秋千套件,反复试验。
编辑:更新。截至 2013 年中,EXT4 似乎表现不错!BTRFS 仍然不是一个好的选择。RHEL 可能会将 XFS 设为新的默认文件系统。再次强调,不要使用 EXT3。
答案4
不太可能有太大区别。只要足够,就使用你的发行版默认的配置。
花费精力调整其他东西 - 获取足够的 RAM - 获取不错的 raid 控制器 - 并修复应用程序对数据库的错误(滥用)使用(注意:在大多数情况下,如果尚未完成,这是罪魁祸首)。
但是,请仔细考虑放置 mysql tmpdir 的文件系统;这会影响性能,特别是执行基于磁盘的 filesort() 的查询(有关更多详细信息,请参阅 EXPLAIN)。
我认为支持延迟分配的文件系统在这里确实很方便,因为当有足够的 RAM 将它们保存在缓存中时,您可以完全避免对短暂文件进行 IO。例如,XFS 根本不会费心写入在分配之前被删除和关闭的文件。
当然,从性能角度来看,将 tmpdir 放在 tmpfs 上很有吸引力,但会导致耗尽空间的风险,并导致原本会成功的查询(尽管使用了磁盘临时文件)失败。