☰

缺乏 TRIM 支持——ZFS + SSD 上的基准测试会变得越来越慢吗？

tag-icon • tag-icon postgresql zfs ssd zfsonlinux trim
缺乏 TRIM 支持——ZFS + SSD 上的基准测试会变得越来越慢吗？

语境：我使用的是东芝 512 GB NVMe（型号：KXG50ZNV512G）

我在 ZFS-on-Linux 上对 Postgres 进行基准测试（通过）时看到了这种奇怪的行为pgbench，基准测试的第二次和第三次运行比第一次运行逐渐变慢。

事情的经过如下：

client=1  |  770 =>  697 | 10% reduction in TPS
client=4  | 2717 => 2180 | 24% reduction in TPS
client=8  | 4579 => 3339 | 37% reduction in TPS
client=12 | 4219 => 4175 | 01% reduction in TPS
client=48 | 5902 => 5623 | 05% reduction in TPS
client=96 | 7094 => 6739 | 05% reduction in TPS

我正在重新运行这些测试，早期的数字表明第三次运行比第一次慢，第四次运行比第三次慢。

Linux 上的 ZFS 缺乏 TRIM 支持是否会导致这种情况 -https://github.com/zfsonlinux/zfs/pull/8255？

答案1

造成您困扰的可能并不是缺少 TRIM 支持（只需在磁盘末尾留下约 10% 的未分区空间即可避免其性能缺陷），而是 ZFS CoW 行为。

基本上，在空数据集上运行时，您可以写入而不会产生读取/修改/写入，因为您还没有写入太多内容。当真正重写数据时（如以下基准测试中所示），您将逐渐产生越来越多的读取/修改/写入，从而导致读取和写入放大（以及性能降低）。

要检查是否确实如此，只需zpool iostat记录前三次运行的总读/写次数：如果您看到第二次和第三次命令增加传输的字节数，则您可以确认上面所写的内容。

答案2

您可以验证该池是否启用了自动修剪。

zpool get autotrim [池名称]

启用该功能可能有助于提高性能。如果没有，您可以尝试使用以下方法启用它：

zpool set autotrim=on [池名称]

留出 10% 的空闲空间也有帮助。但是，如果 SSD 不是全新的，则必须缩小现有分区以留出 10% 的空闲空间。之后，您还必须向该空闲空间发出“blkdiscard”。请注意，blkdiscard 是危险命令，如果您输入错误的地址，可能会清除现有数据。不建议在现有 SSD 上执行此操作。

相关内容