MySQL InnoDB ext3块大小

Question

我正在寻找关于使用ext3的MySQL 5.6文件系统块大小的建议。

在CentOS VMware ESXi 5中运行ESXi 5.4VM，在NetApp FibreChannel LUN(具有4k块大小)上运行VMFS 5数据存储。使用O_DIRECT，innodb_flush_log_at_trx_commit = 2，14G缓冲池，数据库执行OLTP，偶尔会有一些大型查询处理大量数据。有些表是几GB或更多，另一些则非常小。表和ibdata文件位于一个文件系统上，binlog和ib_logfiles位于另一个文件系统上，因此它们可以有不同的块大小。

我知道InnoDB使用16k块大小，这不是用户可配置的，所以我想知道是否值得将ext3块大小设置为匹配，而不是4k默认值。

谢谢!

Answer 1

文件系统块大小不应对InnoDB产生不良影响。我说的不是cpu绑定性能的微小部分，因为它的文件系统开销非常小。您应该担心的是IO性能。

当mysql需要从磁盘读取InnodDB页面时，它会访问文件的inode结构。ext3 inode包含对15个块的引用。前12个点直接指向数据块。其余3点指向块，包含其他块引用，这也可能是直接或间接的。

因此，如果InnoDB页面位于文件的第一个(12*4 )=48 12-它将在2个IO操作中被获取:一个用于inode，第二个用于数据块，如果它位于第一个(12*4+ 1024)*4=4.2MB中，则为3个ops，(12+1024+1024^2)*4=4GB -4 ops，(12*bs+1024+1024^2+1024^3)*4=4TB -5op。

1024是4k块中4字节块引用的数目。

Readahead(用于写入的预分配)和缓存将减少此计数，允许同时读取/写入几个块。

4k的块大小与linux内存页大小相同，使得页面缓存更容易编写代码。

当首次编写Innodb页面时，ext3将预先分配8个顺序块(32 of )并编写其中的4个，其余4个将被丢弃(或用于多一个页面)。对此页的所有更改都将存储在相同的块上。

减少块大小只有利于节省磁盘空间，因为1块是存储在磁盘上的最小数据单位。

增加它(有一些内核补丁可以这样做)将提高非常大的文件的性能，但不像您可能认为的那么多。将其与InnoDB页面大小匹配是没有意义的，因为在大多数情况下，一个InnoDB页面的数据块将顺序放置在磁盘上，并将在单个操作中进行读写。

Answer 2

不过，ext2 2/3的唯一可用块大小似乎是1K、2K、4K。

来自mke3fs(8)手册页：

       -b block-size
          Specify  the  size  of  blocks in bytes.  Valid block size vales are 1024, 2048 and 4096 bytes per block.