☰

使用 ZFS recordsize 16k 而不是 128k 的缺点

tag-icon • tag-icon zfs qemu performance-tuning
使用 ZFS recordsize 16k 而不是 128k 的缺点

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

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

  • 除 MySQL/InnoDB 外，其他数据库均为 128k
  • MySQL/InnoDB 为 16k（因为 16k 是我使用的默认 InnoDB 页面大小）

我添加了 16k 池来检查它是否真的对 MySQL/InnoDB 数据库性能产生了影响。结果确实如此。我的每秒事务数增加了约 40%，延迟降低了 25%（我已经用系统工作台和韓國）。

出于实际原因，我目前更愿意使用一个具有 16k 记录大小的大池，而不是两个独立的部分（16k 和 128k）。我知道，我可以在单个 ZFS 池上创建子卷并赋予它们不同的记录大小，但这也是我想避免的事情。我更喜欢通过 Proxmox GUI 进行管理。

我的问题：

  1. 如果我开始对所有内容使用较小的（16k）记录大小而不是 128k（Proxmox 上的默认设置），我会遇到什么缺点？

  2. QEMU 磁盘映像是否有与 innodb_page_size 等效的项？如果有 - 它的大小是多少？

    我尝试用以下方法检查qemu-img info：

     $ qemu-img info vm-100-disk-0.raw
 image: vm-100-disk-0.raw
 file format: raw
 virtual size: 4 GiB (4294967296 bytes)
 disk size: 672 MiB

服务器使用情况为：

  • www/php 的容器（大量小文件，但位于容器磁盘文件内）
  • java/spring 应用程序的容器（它们会产生大量日志）
  • mysql/innodb 数据库的容器（无需解释）
  • 本地备份/恢复操作，包括压缩备份
  • 处理大型 gzip 文件（不是每天，低优先级）

答案1

简短回答：这实际上取决于您的预期用例。一般来说，默认的 128K 记录大小是机械磁盘上​​的一个不错的选择（其中访问延迟主要由寻道时间 + 旋转延迟决定）。对于全 SSD 池，我可能会使用 16K 或最多 32K（仅当后者为您的数据提供显着的压缩效率提升时）。

长答案：对于 HDD 池，我建议坚持使用默认的 128K 数据集记录大小，并使用 128K volblocksize 作为 zvol。理由是 7.2K RPM HDD 的访问延迟主要由寻道时间决定，而寻道时间不是使用 recordsize/volblocksize 进行扩展。让我们来算一下：7.2K HDD 的平均寻道时间为 8.3ms，而读取 128K 块仅需约 1ms。因此，命令磁头寻道（延迟 8ms+）来读取较小的 16K 块似乎很浪费，尤其是考虑到对于较小的读/写，您仍然会受到 r/m/w 延迟的影响。此外，较小的记录大小意味着更大的元数据开销和更差的压缩。因此，虽然 InnoDB 发出 16K IO，并且对于专用数据集，可以使用 16K 记录大小来避免 r/m/w 和写入放大，但对于混合用途数据集（即：您不仅用于 DB 本身，还用于更一般的工作负载的数据集），我建议保持 128K，尤其是考虑到小记录大小对压缩的影响。

但是，对于 SSD 池，我会使用小得多的 volblocksize/recordsize，可能在 16-32K 范围内。理由是 SSD 的访问时间要短得多，但耐久性有限，因此对于较小的写入，写入完整的 128K 块似乎有些过分。此外，在高 IOP 设备上，大记录大小所要求的 IO 带宽放大比现代 SSD 更令人担忧（即：您有带宽饱和的风险前达到 IOPs 限制）。

答案2

我建议调整如果和当你遇到了问题。

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

例外情况包括：

  • 某些数据库应用程序；较小的值可能更合适。
    代价是压缩效率会大大降低，这可能会对性能产生比更高事务数更大的影响！！
  • 大型媒体工作量（例如视频编辑）；较大的值很有用
  • 超出正常 ZFS 使用情况的特定工作负载

如果你觉得数据库基准测试在特定记录大小下性能更好，那就使用它吧！
但你有没有用一个现实的非标杆工作量来确保你做出正确的调整？

答案3

不管怎样，根据 zfs 文档本身的建议设置“recordsize=16K”。

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

编辑：我刚刚在 proxmox 服务器上为一个具有相当大数据库（>60GB 数据）的虚拟服务器更改了此设置，不到 12 小时就恢复了此设置。服务器在分析数据方面严重落后。事实上，“z_rd_int_' 进程的 CPU 使用率从低跃升至约 5%，而 'z_wr_int_'处理的 CPU 使用率下降 — 可能是因为处理的数据较少。

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

因此，该建议并非在所有情况下都是好的 - 它可以恢复到原始设置。

相关内容