我正在寻找使用 InnoDB 的 MySQL 5.6 的 ext3 文件系统块大小的建议。
在 NetApp FibreChannel LUN(块大小为 4k)上的 VMware ESXi 5、VMFS 5 数据存储中运行 CentOS 5.4 VM。使用 O_DIRECT,innodb_flush_log_at_trx_commit = 2,14G 缓冲池,数据库执行 OLTP,偶尔进行一些大查询处理大量数据。有些表有几 GB 或更多,有些则很小。表和 ibdata 文件在一个文件系统上,binlogs 和 ib_logfiles 在另一个文件系统上,所以它们可以有不同的块大小。
我知道 InnoDB 使用 16k 块大小,这不是用户可配置的,所以我想知道是否值得将 ext3 块大小设置为匹配,而不是默认的 4k。
谢谢!
文件系统块大小不应该对 InnoDB 产生不良影响。我不是在谈论微小的 cpu 绑定性能,因为它的文件系统开销非常小。您应该担心的是 IO 性能。
当 mysql 需要从磁盘读取 InnodDB 页面时,它会访问文件的 inode 结构。ext3 inode 包含对 15 个块的引用。前12位直接指向数据块。其余 3 个指向块,包含其他块引用,也可能是直接或间接的。
因此,如果 InnoDB 页面位于文件的第一个 (12*4)=48KB - 它将在 2 个 IO 操作中获取:1 个用于索引节点,第二个用于数据块,如果它位于第一个 (12*4 + 1024)*4 =4.2MB 3 次操作,(12+1024+1024^2)*4=4GB - 4 次操作,(12*bs+1024+1024^2+1024^3)*4=4TB - 5 次操作。
1024是4k块中4byte块引用的个数。
预读(写入预分配)和缓存将减少此计数,允许一次读取/写入多个块。
4k 的块大小与 linux 内存页面大小相同,使页面缓存更易于编码。
当 Innodb page 第一次写入时,ext3 会预分配 8 个顺序块(32kb)并写入其中 4 个,其他 4 个将被丢弃(或用于多页)。此页面的所有更改都将存储在相同的块中。
减小块大小只会有利于节省磁盘空间,因为 1 个块是存储在磁盘上的最小数据单位。
增加它(有一些内核补丁可以做到这一点)将提高非常大文件的性能,但不会像您想象的那么多。将它与 InnoDB 页面大小匹配是没有意义的,因为在绝大多数情况下,一个 InnoDB 页面的数据块将按顺序放置在磁盘上,并将在单个操作中读取/写入。
没关系,ext2/3 唯一可用的块大小似乎是 1K、2K、4K。
来自mke3fs(8) 手册页: