ACM

ACM通信

首页 / 杂志存档 / 2010年7月(第53卷第7期) / 系统时延可视化 /全文

实践

系统时延可视化

布伦丹·格雷格著
美国学会通讯，2010年7月，第53卷第7期，48-54页
10.1145/1785414.1785435
评论

认为: 打印手机应用程序 ACM数字图书馆全文(PDF) 数码版分享: 通过电子邮件发送在reddit上分享在StumbleUpon上分享分享黑客新闻在推特上分享在Facebook上分享

详细的磁盘I/O数据 — 资料来源:Brendan Gregg / Oracle

当I/O延迟以可视化热图的形式呈现时，会出现一些有趣而美丽的模式。这些模式提供了系统实际执行情况以及终端用户应用程序所经历的延迟类型的洞察。在这些模式中看到的许多特征仍然不为人所知，但到目前为止，他们的分析揭示了以前未知的系统行为。

延迟是花费在等待上的时间，当由应用程序请求的同步组件引起时，它对性能有直接影响。这使得解释变得简单，延迟越高，性能越差。这种简单的解释对于用于性能分析的许多其他统计类型是不可能的，例如利用率、IOPS(每秒I/O)和吞吐量。这些统计信息通常更适合于容量规划和理解工作负载的性质。然而，为了识别性能问题，了解延迟是必不可少的。

对于从应用服务器测量的应用程序协议，延迟可以指从接收请求到发送完成的时间，例如，Web服务器响应HTTP get或文件服务器响应NFS(网络文件系统)操作的时间。这样的测量对于性能分析非常重要，因为客户端和最终用户通常在这段时间等待。

对于资源组件(如磁盘)，延迟可以指发送I/O请求和接收完成中断之间的时间间隔。高磁盘延迟通常会导致应用程序性能问题，但并非总是如此:文件系统可能会周期性地将脏缓存数据刷新到磁盘;但是，I/O对应用程序是异步的。例如，Oracle Solaris ZFS文件系统定期将事务组刷新到磁盘，导致平均磁盘延迟时间激增。这并不反映ZFS使用者所经历的文件系统延迟，因为平均磁盘延迟包括来自事务刷新的异步写入。(如果分别观察读和写延迟，这种误解将有所缓解，因为事务刷新只影响写延迟。)

虽然检查延迟是可取的，但从历史上看，直接测量某些组件是很困难或不可能的。例如，检查应用程序级延迟服务器端可能涉及检测应用程序或检查网络数据包捕获并将请求与响应关联。随着DTrace的引入，¹然而，在生产系统中，实时测量任意点的延迟已经成为可能。

回到顶部

潜伏期热图

考虑到跟踪任意感兴趣点的延迟的能力，问题就变成了该数据的有效可视化表示。繁忙的系统每秒可以处理数十万个I/O事件，每个事件提供一个完成时间和I/O延迟。一种方法是将数据总结为每秒平均延迟和最大延迟，可以用折线图表示。虽然这将允许随着时间的推移检查平均延迟，但如果提供了最大值，则无法识别延迟的实际构成或分布。

为了检查一段时间内的分布情况，可以使用可视化方法，例如热图。在系统可观察性工具中，热图的使用并不频繁，只有一些用于映射磁盘I/O访问模式的外观。这方面的一个例子是taztool(1995)，它显示了一个显示时间的热图x-轴和磁盘I/O偏移量y-轴，允许通过可视化磁盘I/O的位置来识别随机和顺序的磁盘I/O模式。⁵

为了可视化延迟随时间的分布，可以根据时间创建热图x的-axis和延迟y设在。热图是一个像素的彩色阴影矩阵，其中每个像素代表一个特定的时间和延迟范围。在该时间和延迟范围内发生的I/O数量由像素的色度显示:深色表示更多I/O，浅色表示更少I/O。除了显示延迟分布之外，热图还通过寻找延迟最高的像素和最暗的颜色分组来传达关于最大和平均延迟的详细信息。

为了使延迟热图最有效，每个像素表示的时间和延迟范围应该足够大，以允许多个I/O操作在其中。这样可以选择较暗的色调，并观察不同色调所显示的模式。如果范围太小，许多像素可能只代表一个I/O，并且大部分热图可能以相同的颜色阴影出现;它还可以降低相邻像素被阴影化的可能性，并且热图可能看起来更像散点图。

可能的颜色深浅范围可以应用于生成的每个热图。这可以线性应用:I/O最多的像素被赋予最深的颜色，所有其他像素被赋予从最深的I/O计数缩放的阴影。这种方法的一个缺点是重要的细节可能会被洗掉。检查偏离标准的延迟尤其重要，特别是出现高延迟的情况。由于这些可能只代表了工作负荷的一小部分(可能不到1%)，颜色阴影可能非常浅，很难看到。可以使用一个错误的调色板来突出这些微妙的细节，因为这样就不能使用颜色深浅来衡量像素之间的相对I/O计数。

热图可视化的一个特别优势是能够看到异常值。对于延迟热图，这些可能是具有特别高延迟的偶尔I/O操作，这可能会导致严重的性能问题。如果y-轴比例自动选择显示所有数据，异常值很容易识别为热图顶部的偶尔像素。这也带来了一个问题:具有高延迟的单个I/O将重新缩放y-轴，压缩大量数据。如果需要，可以消除异常值，以便详细检查大量I/O。一种自动的方法可以是在需要时从显示中删除一个百分比(比如0.1%)的最高延迟I/O。

为了生成时延热图，需要收集每个I/O事件的数据:完成时间和I/O时延。然后将这些数据分组到热图的时间/延迟像素中，并根据它们的I/O计数对像素进行阴影处理。如果保留了原始I/O事件数据，则可以在任何时间和延迟范围内以不同的分辨率重新生成热图。这样做的一个问题是数据的大小:繁忙的生产系统可能每秒要处理数十万个I/O事件。在很长一段时间内(如几天或几周)持续收集这些数据，对于存储所需的数据和处理和生成热图的时间来说，可能都是不可能的。一种解决方案是将这些数据汇总到足够高的时间和延迟分辨率，并保存汇总的数据。在显示热图时，这些摘要将被重新采样到所需的分辨率。

回到顶部

热点图解释

延迟热图作为Oracle系统可观察性工具Analytics的一部分实现。该实现允许实时查看它们，并以一秒的粒度连续记录数据以供以后查看。DTrace使这成为可能，并且是最优的，DTrace能够跟踪和总结内核中的数据到足够的分辨率，并每秒钟将这些摘要返回给用户。然后，用户土地软件对汇总的数据进行重新采样，以生成热图。

的热点图图1，一个来自Analytics的示例截图，显示了NFS读工作负载的延迟分布，以及使用附加的基于闪存的缓存层时对NFS延迟的影响。缓存层在19:31:38启用，该缓存层集中在x-axis。详细解释此热图将显示此可视化对于理解这些系统组件的角色及其对交付的NFS延迟的影响是多么有效。

在这张截图中，热图的左侧显示了一个显示平均IOPS计数的面板。面板上方和下方的“Range average:”和“8494 ops / s”显示可见时间范围内的平均NFS I/O每秒(x设在)。在面板中是延迟范围的平均值，第一个显示0到333秒之间的平均NFS IOPS为2006。每个延迟范围对应于热图上的一行像素。

对于19:31:38之前的时间，为NFS服务的系统从两个位置之一读取:基于dram的缓存或磁盘存储。如果请求的I/O不在DRAM缓存中，则从磁盘检索它。在热图中，可以看到两个级别的延迟。这些对应于:

DRAM命中，显示为热图底部的暗线
磁盘命中，显示为2毫秒或更高的延迟阴影云

这是意料之中的。DRAM命中具有非常低的延迟，并显示在最低延迟像素中。该像素表示0到333秒之间的延迟，这是当前显示的热图的分辨率限制。由于记录的数据具有较高的分辨率，因此可以用不同的垂直比例尺重新绘制该热图，以揭示更精细的细节。通过放大到较低的延迟，发现DRAM命中大部分在0到21秒的范围内。²

磁盘命中的延迟分布很广，从大约2ms到显示的热图顶部为10ms。返回的磁盘I/O延迟包括旋转、寻道和总线I/O传输时间。由于磁盘是通过随机I/O模式访问的，因此仅旋转延迟就可以加起来高达8.3 ms，这是在这些磁盘上完全旋转的时间。这种旋转潜伏期被认为是热图中所看到的大部分随机模式的原因。

19:31:38之前的热图还确定了I/O不太频繁的延迟范围:在DRAM命中和磁盘命中之间，从334秒到大约2毫秒的较轻的频带。混合存储池已经解决了这个延迟差距⁴在ZFS⁶通过增加基于闪存的缓存层。闪存比DRAM慢，比磁盘快，并以ssd(固态硬盘)的形式合并到这个NFS服务器中。然后，NFS读取可以从以下三个位置之一(按优先级排序)提供:基于dram的缓存、基于闪存的缓存或磁盘存储。

启用基于闪存的缓存发生在19:31:38，之后可以看到三个级别的延迟:

DRAM命中，显示为热图底部的暗线
SSD命中，延迟小于约2ms
磁盘命中，由于增加了额外的缓存层，磁盘命中变得更轻，因为到达磁盘的请求更少了

该热图显示基于闪存的缓存减少了I/O的延迟，否则将从磁盘提供服务。所有三个系统组件都是可视化的，以及它们的延迟范围和该范围内的延迟分布。它还显示磁盘I/O仍然发生，尽管速度有所降低。这些都是热图可视化所提供的有用信息。想象一下，将这些数据显示为平均延迟的折线图:唯一可见的信息是启用缓存时平均延迟的小幅降低(之所以很小，是因为平均延迟将被大量DRAM命中所支配)。

大多数热图都像这张图一样容易理解。下面是我们发现的意想不到的热图，展示了我们还没有完全理解的有趣模式。

回到顶部

冰湖

工作负载和目标很简单:单个客户端有一个线程对NFS共享执行顺序同步的8KB写操作。NFS服务器有22个7200rpm的磁盘，作为ZFS条带池的一部分。

由于这些都是同步写入，所以只有将数据写入稳定的存储中，NFS请求才能完成。这个测试没有使用基于闪存的日志设备，因此延迟预计会很高，因为数据必须写入7200rpm的磁盘。

您可能期望延迟随机分布在0到10毫秒之间，并且热图显示为白噪声。实际结果如图所示图2．

潜伏期不是随机分布，而是在不同的水平上组合在一起，随着时间的推移而上升和下降，形成了一种被称为冰湖的模式。这是出乎意料的，特别是考虑到工作负载的简单性。

这种行为不能仅从平均或最大延迟来确定，想象压缩y-轴信息转换成单线图。在检查每个I/O事件时，例如使用基于dtrace的iosnoop工具在磁盘级进行跟踪，这也具有挑战性，因为数据量非常大(数千行输出)。

理解这种模式的第一步是检查22个磁盘中是否每个磁盘都有不同的行。图3显示来自单个磁盘的磁盘I/O延迟，这确认每个磁盘都为模式贡献了行。

下一步是调查为什么有些线增加而有些线减少。增加的原因可能是应用程序请求I/O与磁盘旋转同步，并且ZFS沿磁盘磁道写入扇区，这增加了每个I/O的磁盘旋转延迟(尽管这没有解释延迟如何在某些磁盘上增加而在其他磁盘上减少)。

为了简化问题，使用单个磁盘池重复测试。图4显示大部分NFS延迟在7.86ms到8.20ms之间，接近7200rpm磁盘的8.33ms转速。检查了磁盘I/O偏移量(使用Analytics和iosnoop)，结果显示ZFS在整个磁盘上按顺序写入8KB I/O。NFS延迟较小的原因可能是客户端和网络延迟:一旦一个I/O完成，当NFS完成发送给客户端时，磁盘继续转动;客户端处理它，请求下一次写入，然后请求对磁盘进行下一次写入。当发生这种情况时，磁盘已经旋转了一点，因此不需要完全旋转来写出下一个偏移量。这可以解释热图中显示的大部分I/O;然而，顶部线条的原因仍然未知(它显示了平均每秒一个I/O，从9.29ms到9.64ms，并且通过Analytics使用的假调色板清晰可见)。

ZFS通过写入zil (ZFS意图日志)来实现同步写入，这些zil稍后被分组并作为TXG(事务组)刷新到磁盘。期望按顺序写入ZIL，因此热图也符合预期(除了顶部的行)。对于双盘条纹池，这将有所不同，因为ZFS在每个磁盘上都有一个ZIL，并以循环方式写入它们。这是经过测试的图5显示了双盘池上的NFS延迟以及池中每个磁盘的磁盘I/O延迟。延迟增加和减少的原因现在可以从理论上解释:当一个磁盘上的延迟增加时，另一个磁盘继续旋转，并且在发出请求时具有相应的更小的延迟。的热点图图2是这个的扩展，用了22个磁盘而不是2个。

斜坡的最初原因仍未查明。磁盘正在写入一个稳定增加的偏移量，该偏移量预计将沿着磁盘轨道以顺序的方式放置(这取决于磁盘对它的实际用途)。如果旋转的起始点是固定的，那么每次写入的旋转延迟将随着磁盘进一步旋转以达到增加的偏移量而稳步增加(直到达到完整的旋转)。然而，起点并不是固定的;相反，它是前一个I/O的结束点，其中包括开始偏移量和I/O大小。由于每个偏移增量和I/O大小都相同，所以到下一个I/O的旋转延迟也应该相同。与单盘池分析一样，在磁盘继续旋转时，斜率实际上可能是客户机和网络延迟的结果。斜率变化的原因也是未知的，如图5在20:10:00到20:10:45之间。

在镜像、单奇偶校验和双奇偶校验RAID等其他存储配置上测试了该工作负载。图6将此工作负载显示到22个磁盘的镜像池。这里，ZIL是跨对磁盘镜像的，直到ZIL存在于镜像的两侧，才认为对稳定存储的写入已经完成;因此，NFS I/O延迟来自pair中最慢的磁盘。这使得热图偏向于更高的延迟。对于单奇偶校验和双奇偶校验RAID(此处不包括它们的热图截图)，可以看到类似的更大的效果。

总结一下我们对冰湖的了解:线来自单个磁盘，磁盘对会导致延迟的增加和减少。导致这种模式的潜伏期随时间而变化的实际原因还没有被确定;是什么导致增加/减少的速率发生变化(斜率的变化见图5)亦未知;并且，在单磁盘池中看到的更高的延迟线(图4)也尚未被理解。以这种方式可视化延迟显然带来了更多的问题而不是答案。

回到顶部

彩虹翼手龙

和冰湖一样，彩虹翼手龙是另一种简单的工作，却产生了令人惊讶的复杂图案。这次的磁盘I/O延迟是在两个JBOD(只是一堆磁盘)框中有48个磁盘的系统上检查的。执行一个本地工作负载来调查I/O总线吞吐量，方法是逐个添加具有连续128KB读取的磁盘，同时查找吞吐量图中的拐点。延迟预期与所使用的I/O大小一致，并显示为一条窄线，可能随着I/O子系统总线(包括HyperTransport、PCIe和SAS)上争用的增加而略有增加。当其中一个总线达到饱和时，预计延迟将急剧增加。因此，只有两个特性是预期的:随着一致的延迟逐渐增加，然后由于争用而使延迟变得不一致而急剧增加。

图7显示此测试的吞吐量图和延迟热图。每两秒钟就有一个新磁盘被添加到工作负载中，在磁盘吞吐量图中可以在17:55看到一个拐点。找到这个膝盖点是这个实验的最初目的;然而，最吸引人眼球的是潜伏期热图。我们把它命名为彩虹翼手龙。

磁盘I/O字节图(彩虹)显示了三个特征:最初的上升，然后是斜率下降，然后是衰减。通过将圆盘图与热图相对应，可以看到热图中的特征发生在特定的圆盘计数上。热图显示了以下特征。

“喙”出现在磁盘1到磁盘8之间。两级延迟的原因还不完全清楚，但一个实验提供了一个线索:如果重复读取相同的数据以确保磁盘缓存被访问，那么只有一行的延迟较低。当按顺序读取这些磁盘时，会出现两行模式，这表明第二行是用于磁盘缓存丢失的。使用标准工具进一步分析这个问题是很困难的:对磁盘的输入及其返回的延迟可以跟踪，但是对磁盘内部(如磁盘数据控制器的操作)没有可见性。

当添加第九个圆盘时，喙变成了“头”。硬盘通过2根SAS线缆连接，每根端口为x4，共提供8个SAS端口。访问第九个磁盘可能会导致在SAS控制器中的这些端口上的争用和相应的随机延迟模式。当磁盘使用单根x4 SAS电缆连接时，在第五个磁盘发生鸟喙到磁头的转换。

在磁盘9和12之间的磁头顶部形成了一个“凸起”，显示延迟略有增加。造成这种情况的原因尚不确定，但可能是因为SAS端口的争用日益增加。在磁盘13和14上形成“颈部”的延迟减少的原因也不为人所知。

大约在15号盘和20号盘之间是“翼”。延迟的突然增加导致了磁盘吞吐量图中的膝盖点。这种争论的来源尚不清楚，尽管另一个磁盘缩放实验使用一根x4 SAS电缆连接到一个JBOD，产生了一个无翼翼龙。

从大约磁盘20开始，当磁盘继续添加时，延迟会继续增加，并且变得不那么一致。这预计是SAS控制卡上的PCIe-gen1总线争用。

热图显示了所有这些特性，但构成输入的单个I/O事件却完全不知道这些特性:它们只提供完成时间和I/O延迟，而磁盘计数则增加了。热图根据这些数据对I/O子系统进行了成像，显示了被怀疑是磁盘缓存、SAS端口和PCIe总线的组件。

总结一下彩虹翼手龙:准确的了解很少，还需要更多的研究。这确实表明了一个简单的可视化可以变得有多深刻。

回到顶部

延迟的水平

对于彩虹翼龙，I/O总线吞吐量通过步进顺序磁盘读取工作负载进行测试。在一个具有更强大的I/O子系统的不同系统上重复了这种情况，并且发现从所有可用磁盘的顺序磁盘读取无法达到I/O总线饱和(没有膝点)。为了查看是否可以找到限制，将工作负载更改为重复从每个磁盘读取相同的128KB，以便每个磁盘仅通过从其缓存返回就可以提供更多吞吐量。结果显示在图8．

在15:39和15:40之间达到了一个膝盖点，尽管在磁盘字节图中很难看到。此时，会出现一定程度的延迟;稍后，还有另一个关卡(在这张截图中被选中)。在不同的点上，似乎延迟级别已经提升到更高的级别。这是最近才发现的，到目前为止还不清楚。这里提供它作为延迟热图所揭示的意外细节的另一个示例。

回到顶部

对jbod大喊大叫

虽然没有前面的例子那么漂亮，但下一个热图背后的故事已经获得了一些名声，值得强调的是，这是一个识别问题的延迟热图。

该系统包括几个带有数十个磁盘的JBODS，并正在执行流写工作负载。我发现，如果我尽可能大声地对着jbod大喊，磁盘返回的I/O将具有极高的延迟。图9这是这次不寻常测试的热图。

热图显示了两个潜伏期峰值，对应于我的每一个呼喊。我们把这一发现录了下来，并上传到YouTube上，在那里我把这种效果描述为磁盘振动。^3.从那以后，有人提出，由于呼喊的音量，这更应该被描述为冲击效应，而不是振动。

热图中显示的受影响的磁盘I/O有非常高的延迟，超过1秒。如果跟踪平均延迟，那么在同时执行超过8000个更快I/O事件的系统上，一些高延迟I/O事件可能会被淹没。这一经验的教训是潜伏期热图如何很好地识别这种扰动。

回到顶部

其他应用程序

前面的示例展示了部署通过NFS访问的ZFS文件系统的系统的延迟热图。延迟热图也适用于其他本地和远程文件系统类型(例如，UFS、HFS+、CIFS)，可以用类似的方式识别和解释这些类型的特征。例如，部署在Solaris上的UFS (Unix文件系统)执行名为fsflush定期将脏数据写入磁盘。这可以更新磁盘上间隔的UFS圆柱组块，导致查找和旋转延迟导致的高延迟I/O。在旧版本的Solaris上，写入之间的间隔为5秒(调优_ t_ fsflushr)，因此在磁盘I/O的延迟热图上，这可能很容易识别，出现为间隔5秒的高延迟爆发。

热图可视化也可以应用于其他指标，除了延迟。上的大小(字节)可以可视化为热图y-axis，允许识别任何特别大或特别小的I/O，由于不同的原因，它们都很有趣。I/O位置可以可视化为热图(如前所述)，在y-轴，允许随机或顺序的I/O被识别。

组件的利用率还可以可视化为热图，显示单个组件的利用率百分比，而不是显示所有组件的平均利用率百分比。利用率可以显示在y-轴，该利用率的组件数量可以通过热图像素的颜色显示。这对于检查磁盘和CPU利用率以检查负载如何在这些组件之间平衡特别有用。一组较深的颜色表示负载均衡，一组较浅的像素表示负载不均衡。

离群值也很有趣:利用率为100%的单个CPU可能在热图顶部显示为一条浅色线，通常是软件可伸缩性问题(单线程执行)的结果。利用率为100%的单个磁盘也很有趣，这可能是磁盘故障的结果。这不能仅使用平均值或最大值来识别:最大值不能区分利用率为100%的单个磁盘和利用率为100%的多个磁盘，这可能发生在正常的负载突发期间。

这里提到的所有热图都已在Analytics中实现。事实证明，与I/ o延迟热图一起，利用率热图对于快速识别性能问题特别有用。

回到顶部