缺少TRIM支持--在ZFS + SSD上基准会逐渐变慢吗？

Question

上下文:我使用的是东芝512 GB的NVMe (Model: KXG50ZNV512G)

在ZFS(通过pgbench)上对Postgres进行基准测试时，我看到了这种奇怪的行为，在这种情况下，基准测试的第二和第三次运行比第一次运行慢。

下面是正在发生的事情：

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

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

ZFS上缺乏TRIM支持会导致这种- https://github.com/zfsonlinux/zfs/pull/8255吗？

Answer 1

而不是缺少的TRIM支持(您通常可以通过在磁盘末尾保留10%的未分区空间来避免其性能缺陷)，而可能是影响您的是ZFS CoW行为。

基本上，在一个空的数据集上运行时，您可以编写而无需读取/修改/写入，因为您还没有编写很多东西。当真正重写数据时(如下面的基准测试所示)，您将越来越多地读/修改/写数据，从而导致读和写放大(以及性能下降)。

要检查是否是这种情况，只需使用zpool iostat记录前三次运行中的总读/写:如果您看到第二次和第三次命令增加了传输字节的数量，则可以确认上面所写的内容。

Answer 2

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

获得自动修剪的池名

把它打开可能有助于表演。如果没有，您可以尝试通过以下方式启用它：

兹普尔集autotrim=on 池名

留出10%的空空间也会有帮助。但是，如果ssd不是全新的，则必须缩小现有分区，以省略10%的空空间。在此之后，您还必须向该空空间发出"blkdiscard“。请注意，blkdiscard是危险的命令，如果输入错误的地址，该命令可能会删除现有数据。不建议在现有的ssd上这样做。