在Delphix，我们一直在努力提高业绩。有些增强来自于我们看到需要解决的性能问题的客户，而有些增强来自于我们对Delphix操作系统瓶颈的理解。在过去的几个月里，georgewilson和adamleventhal对ZFS中如何处理写操作进行了重大改进。在这篇由多个部分组成的博客文章中，我将讨论我们创建的一个基准测试：在我们对操作系统进行更改时测量ZFS write性能的改进。在这篇文章中，我将讨论基准设置和运行。我将在Delphix操作系统上展示这个基准测试的一些结果。在第二部分中，我将介绍一些数据和一些分析，这些数据和分析将如何解决这些瓶颈问题。基准基准测试是一个简单的程序，它将随机数据写入文件中的随机偏移量。我惊喜地发现，我能从这个简单的20行程序中学到很多东西。希望这里有一些信息可以帮助你们中的一些人。这个程序是由Adam和George设计的，用来观察ZFS在zpool碎片化时的行为。**randFd=打开（"/dev/urandom"，仅限O\RDONLY）；Tufd=打开（argv[2]，O_CREAT.O_WRONLY.O_APPEND，0777）；***同时（1）{*RandFd，buf，sizeof（char）*块大小；*块尺寸）；**我在干净的zpool上运行该程序，并使用DTrace观察了系统的性能。程序在写入随机偏移量时将池分段。我想测量作为zpool使用率函数的稳态吞吐量（10%满，50%满等等）。这将演示有趣的ZFS病理学，并跟踪我们从一个版本到另一个版本的进展。基准设置在每次运行之前，我使用以下命令创建了一个新的zpool和一个记录大小为8k的文件系统。zpool创建域c3t1d0zfs create-o recordsize=8k-o compression=on域0/测试我使用了一个8vcpu虚拟机，有48GB的RAM和32GB的池大小用于Delphix服务器。我用了一个小的游泳池，这样我就可以很快地把它装满。虽然32GB远远小于一个典型的客户池，但我相信其结果仍然具有代表性。我运行了8个程序的并发实例来生成负载。（我还用不到8位作者测试了这个基准测试，它显示了类似的特性，但达到稳定状态需要更长的时间。）基准运行一旦我创建了一个zpool，我就用"dd"填充它。*dd if=/dev/urandom of=/domain0/tests/测试文件x.datb=8k计数=Y当池已满时，我使用dtrace监视文件系统。下面的输出显示了运行上述"dd"命令时在后端存储执行的IOs的柱状图（按大小）。大多数写操作的大小是64K和128K，尽管我在用户级别写了8k。这种聚合在ZFS的IO层执行。2013年2月16日18:45:42（经过14.999s）/engineering/uday/scripts/io.d万岁万岁还有很长的路要走。那是很久以前的事了。从1024点开始已经很久了。从2048年开始已经很久了。从4096年开始已经很久了。那是很久以前的事了。从16384年开始已经很久了。一天结束时，有很多乐趣。从65536起已经很久了。回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：回复：。那是很久以前的事了。长期潜伏期写总持续时间的总持续时间ZFS将每个IO设备划分为几百个称为"元板"的区域。下面的图1显示了使用上面的"dd"命令将zpool填充到25%之后的可视化效果。每个单元代表一个元板。这里的池有256128MB的元板。%1（%2）百分比值是每个元板中的可用空间量。如您所见，大约有32个元板已满，占8GB的数据量。[captionalign="aligncenter"width="490"caption="图1：使用顺序写入填充了25%磁盘后的Metaslab利用率"][/caption]在这一点上，池是紧凑的-大多数元板要么是满的，要么是空的，占用的磁盘空间最小。当我在zpool处于上述状态时启动我的程序时，我看到了高写吞吐量的最初激增，随后在一段时间后吞吐量急剧下降。下面的图2描述了程序运行30分钟后的zpool—请注意池仍然只有25%的满。即使程序运行了几个小时，这个图像也没有改变，基准已经达到稳定状态。[captionalign="aligncenter"width="490"caption="图2:zpool使用随机写入写入后的Metaslab利用率仍然只有25%。[/caption]正如您所看到的，池在这一点上是相当分散的。池不是紧凑的，使用的元板数量是2.5倍。大多数元板都有自由空间区域。怎么回事？当程序开始写入zpool中的随机块时，ZFS试图通过分配新的元板来将随机块放置在池的相邻区域中。由于写时复制，每次重写块时，它都会在池中的某个位置创建一个洞。新的数据块被分配给新的元板，直到ZFS在当前分配的元板中找到空闲区域。此时，ZFS开始在分配到新的元板之前填充这些漏洞。因此，在测试中的某个点之后，所使用的元板数量没有增加。下面图3中的图表显示了在基准测试期间，在zpool的不同使用级别下的写吞吐量。[captionalign="aligncenter"width="507"caption="图3:zpool碎片化时的随机写入吞吐量"][/caption]在初始的高写吞吐量之后，基准测试的吞吐量会急剧下降。稳态吞吐量是用实验中最后50个样本的平均吞吐量来计算的。稳态吞吐量与基准运行开始时zpool中的可用空间量成正比。下面图4中的图表根据zpool占用率绘制了这个吞吐量。[captionalign="aligncenter"width="496"caption="图4:zpool占用率不同级别下的稳态写入吞吐量"][/caption]结论实验表明，随着ZFS池变得越来越满和越来越零散，这是一个有趣的性能病理现象。通过运行基准测试可视化元板及其使用情况，有助于理解性能下降背后的原因。上面的图4显示了池中可用空间量与实现的随机写入吞吐量之间的紧密关联。这个测试为将来的ZFS性能工作提供了一个有趣的基准。我们可以将曲线向右推，延迟性能下降的时间点，并将曲线推高，从而改善最坏的情况。一个简单的喷泉20行程序被证明是有用的。在我的下一篇博客文章中，我将更详细地分析结果，并提供一些关于ZFS正在做什么的见解，以及我们可以如何改进它。