使用ZFS记录大小为16k而不是128 k的缺点

Question

我在专用服务器上使用Proxmox。对于生产，我仍然在使用ext4，但我决定开始使用ZFS。

因此，我创建了两个具有不同记录大小的独立ZFS存储池：

• 128 K除MySQL/InnoDB外
• 16k用于MySQL/InnoDB (因为16k是默认的InnoDB页面大小，我正在使用)

我添加了16k池来检查它是否真的对MySQL/InnoDB数据库性能产生了影响。所以真的是这样。我每秒有大约40%的事务处理，延迟降低25% (我已经用系统工作台和tpcc对此进行了彻底的测试)。

出于实际原因，现在我更愿意使用一个大池，它的记录大小为16k，而不是两个单独的部分(16k和128 k)。我知道，我可以在单个ZFS池上创建子卷，并为它们提供不同的记录大小，但这也是我想避免的。我更愿意通过Proxmox来管理这一点。

我的问题：

1. 如果我开始使用一个小的(16k)记录大小而不是128 k(它是Proxmox的缺省值)，我会遇到什么缺点？
2. QEMU磁盘映像是否与innodb_page_size相当？如果是的话-是什么尺寸的？我尝试用qemu-img info：$qemu- info vm-100-dis-0检查它。原始映像:vm-100-dis-0原始文件格式:原始虚拟大小:4 GiB (4294967296字节)磁盘大小: 672 MiB

服务器使用情况是：

• 用于www/php的容器(大量的小文件，但在容器磁盘文件中)
• java/spring应用程序的容器(它们生成大量的日志)
• mysql/innodb数据库的容器(不需要解释)
• 本地备份/还原操作，包括压缩备份
• 乱搞大的gzip文件(不是每天，低优先级)

Answer 1

简短的回答:这真的取决于你期望的用例。通常情况下，默认的128 K记录大小在机械磁盘上是一个很好的选择(在机械磁盘上，访问延迟主要是寻求时间+旋转延迟)。对于一个所有的SSD池，我可能会使用16K或最多32K (只有在后者为您的数据提供了显著的压缩效率提高时)。

长答案:对于HDD池，我建议对数据集使用默认的128 K记录大小，对于zvol也使用128 K卷大小。其基本原理是，7.2K RPM的访问延迟主要是由搜索时间决定的，该时间不随记录大小/卷块大小而缩放。让我们做一些数学:一个7.2K硬盘的平均搜索时间为8.3ms，而读取128 K块只需1ms。因此，命令头部查找(使用8ms+延迟)读取一个小的16K块似乎是浪费的，特别是考虑到对于较小的读/写，您仍然受到r/m/w延迟的影响。此外，小的记录大小意味着更大的元数据开销和更糟的压缩。因此，虽然InnoDB发布16K IOs，对于专用数据集，可以使用16K记录大小来避免r/m/w和写入放大，而对于混合使用的数据集(即不仅用于DB本身而且用于更一般的工作负载的数据集)，我建议保持在128 K，特别是考虑到小记录大小带来的压缩影响。

然而，对于SSD池，我将使用一个更小的体积/记录大小，可能在16-32K的范围内。其基本原理是，SSD的访问时间要短得多，但持续时间有限，因此为较小的写操作编写完整的128 K块似乎太过了。此外，由大记录大小控制的IO带宽放大在高IOP设备上作为现代SSD(即，在达到IOP限制之前就有饱和带宽的风险)更值得关注。

Answer 2

我建议您在遇到问题时进行调优。

ZFS默认为128 K记录大小，这对于大多数配置和应用程序来说都是可接受的和有效的。

这方面的例外包括：

• 某些数据库应用程序；较小的值可能是合适的。的权衡是压缩将大大降低效率，这可能对性能的影响比更高的事务计数！
• 大的媒体工作负载(例如视频编辑)；更大的值是有用的
• 属于常规ZFS用例之外的特定工作负载

如果您认为数据库基准测试的性能在一定的记录大小下更好，请使用它！

但是，你是否测试过一个现实的、非基准化的工作负载，以确保你正在为正确的事情进行调整？

Answer 3

就其价值而言，建议根据zfs的文档本身设置"recordsize=16K“。

https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#innodb

编辑:我只是在对带有相当大的数据库(>60 it的数据)的虚拟服务器的proxmox服务器上更改它不到12个小时之后才恢复该设置。服务器在分析数据方面严重落后。事实上，“z_rd_int__”进程从较低的CPU使用率跃升到大约5%，而“z_wr_int__”处理的cpu使用率下降了--可能是因为处理的数据较少。

然而，将哈希算法更改为edonr (zfs set checksum=edonr vmpool)确实产生了积极影响：perf top不再将SHA256TransformBlocks显示为顶级核函数。

因此，该建议似乎并非在所有情况下都是好的--它可以恢复到原来的集合。