MySQL InnoDB ext3块大小

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

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

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

谢谢！

文件系统块的大小不应该对InnoDB产生不好的影响。我不是在谈论cpu-bound性能的一小部分，因为它的文件系统开销是微乎其微的。你应该担心的是IO性能。

当MySQL需要从磁盘读取InnodDB页面时，它会访问该文件的索引节点结构。 ext3 inode包含15个块的引用。首先直接指向数据块。剩下的3个指向块，包含其他块引用，也可能是直接的或间接的。

因此，如果InnoDB页面首先放置（12 * 4）= 48KB文件 – 它将在2个IO操作中获取：1个inode，另一个数据块，如果它位于第一个（12 * 4 + 1024）* 4 （12 + 1024 + 1024 ^ 2）* 4 = 4GB-4 ops，（12 * bs + 1024 + 1024 ^ 2 + 1024 ^ 3）* 4 = 4TB-5 ops。

1024是4k块中4byte块参考的数量。

分机块

预读（预分配写入）和caching将减less这个数量，允许一次读/写多个块。

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

当innodb页面第一次写入时，ext3将预先分配8个连续块（32kb）并写入其中4个，其他4个将被丢弃（或用于多一页）。对这个页面的所有改变将被存储在相同的块上。

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

增加它（有一些内核补丁可以做到这一点）可以提高非常大的文件的性能，但并不像你想像的那样大。将它匹配到InnoDB页面大小是毫无意义的，因为绝大多数情况下，一个InnoDB页面的数据块将顺序放置在磁盘上，并将在单个操作中读取/写入。

没关系，ext2 / 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.