A Flexible I/O Tracer for Workloads’ I/O Pattern Characterization

摘要

存储系统变得越来越复杂，无法处理HPC和大数据要求。这种复杂性触发了执行深入评估，以确保所有系统层中都没有问题。但是，出于简化的原因，当前的性能评估活动是围绕高级指标执行的。因此，不可能在Linux I/O堆栈的较低层中捕获潜在的I/O问题。在本文中，我们介绍了IOscope跟踪器，用于发现存储系统工作负载的I/O模式。它对Linux内核中的细粒度条件执行基于过滤的分析。依靠扩展的Berkeley数据包过滤器（eBPF）技术，IOscope的内核开销几乎为零，并且已验证行为。我们通过对MongoDB和Cassandra的性能研究证明IOscope的能力，以发现与模式相关的问题。结果显示集群MongoDB受苦不管使用了哪种存储支持（HDD或SSD），都从嘈杂的I/O模式启动。因此，IOscope有助于改善故障排除流程，并有助于深入了解I/O性能

介绍

存储系统变得复杂以跟上HPC和大数据的需求。当前评估存储系统（尤其是数据存储）的方式尚未充分改变。它仍然专注于高层指标，该指标完全忽略了较低接口中的潜在问题。例如，像[12、1、11、8]这样的研究都使用YCSB [5]基准。他们的核心评估指标受限于工作负载的吞吐量和执行时间。人们可能会知道为什么给定系统会获得中等或奇怪的结果，但是不幸的是，此类指标无法解释I/O性能。他们仅表示出了问题。因此，需要进行深入的评估，例如评估I/O活动和较低层中的交互。它导致解释高级测量并检查生产工作负载。因此，我们主要关心的是分析工作负载执行期间如何访问数据文件，调查这种经验是否导致发现潜在的I/O问题。

从此以后，我们将工作负载的I/O模式定义为访问磁盘数据时I/O请求所针对的文件偏移量的顺序。 由于各种原因，可能会出现潜在的I/O问题。 例如，在I/O堆栈的较低层中对I/O请求进行重新排序或在应用层中发生内容分发问题，可能会将顺序访问转换为随机访问，反之亦然。 但是，由于两个原因，在评估过程中很少进行I/O模式分析。 首先，缺少直接分析生产中I/O工作负载的特定工具。 其次，这被认为是内部测试程序，通常会面临这样一个约定：所有存储系统都在内部进行了良好的测试。

跟踪被广泛用于评估存储系统[23]。 跟踪工具通常从多个I/O堆栈层收集通用I/O跟踪。 这不仅会导致Linux内核内部和外部大量多样的拦截产生高昂的开销，而且还会导致生成大量的跟踪文件，而这些文件需要大量的后期分析工作。 相反，多种跟踪工具足以收集精确的数据。 但是，它们部分涵盖了存储系统用于发布I/O工作负载的主要方法。

本文的主要贡献如下。 首先，我们介绍IOscope3跟踪器。 IOscope通过依赖eBPF来应用跟踪和过滤技术，这会产生可忽略的开销[21，20]。 IOscope通过生成特定的可视化跟踪来解决上述限制关于工作负载的I/O模式； 它还涵盖了发行I/O工作负载（包括mmap I/O）的主要方法。 其次，我们描述了使用IOscope在MongoDB和Cassandra上进行的原始实验。 结果表明，集群式MongoDB中与模式相关的问题是实验性能差异的背后。 然后，我们提出一个临时解决方案来解决该问题

相关工作

Betke和Kunkel [3]提出了用于实时I / O监视的框架。在拦截I/O跟踪期间，它没有实现像IOscope这样的过滤机制，从而导致收集了大量的常规跟踪。 Daoud和Dagenais [6]提出了一个基于LTTng的框架来收集磁盘指标。他们的框架仅分析生成的HDD痕迹，而未提供有关其在SSD上的适用性的信息。另外，不收集文件偏移量，这是我们分析工作负载的I/O模式的主要指标。郑先生al [10]提出了一种工具来生成I/O工作负载并分析Android系统的I / O性能。他们的I/O性能分析器需要修改后的内核，并且只能在自定义文件系统（ext4，fat32）上运行。相反，IOscope不需要内核修改，主要在VFS层上工作，以支持大量文件系统。其他工具[14、15、4、24、22]旨在通过分析和重放少量跟踪来预测和推断大规模部署的I/O性能。相反，我们的工作重点是收集细粒度的正在研究用于发现和解释I/O问题的I/O工作负载。

诸如SystemTap [9]，Dtrace [17]，LTTng工具[7]之类的跟踪工具将跟踪脚本作为动态模块加载到内核中（例如，使用dkms软件包）。 这使得它们不适合在某些情况下使用，例如在签名内核的情况下。 使用它们还意味着需要进行后继工作以分析大量收集的痕迹。 相比之下，Linux内核正式采用了eBPF [13]。 我们主要利用它的过滤功能而闻名构建IOscope。

IOscope执行四个活动：对I/O模式进行概要分析，筛选，跟踪和直接分析。其过滤和跟踪活动可与BCC项目的几种工具相提并论[18]。通常，它们提供目标检测点上匹配事件的即时视图，并提供类似于Linux的top命令的输出。 BCC较慢的工具旨在以较大的延迟过滤I/O操作。它们在更高级别的Linux I/O堆栈上工作。 fileslower工具可跟踪Linux I/O堆栈的VFS层上的操作，而ext4slower工具可用于Ext4文件系统。两者都带来了对I/O的细粒度过滤（例如，每个进程报告I/O），但是处理了部分I/O上下文。 fileslower不适用于pvsync，pvsync2和mmap I/O，而ext4Slower缺少支持mmap I/O。对于支持的I/O上下文，仍然可以提取I/O模式。但是，与不需要准备最终结果的IOscope相比，这需要大量的后期分析工作。

总结

必须执行对存储系统工作负载的深入分析，才能发现较低级别的潜在I/O问题。需要强大而灵活的工具来执行此类详细评估。在本文中，我们首先介绍了IOscope，它揭示了存储工作负载的I/O模式。它的开销不到1％，并且继承了eBPF技术的其他功能，适用于分析生产工作负载。然后，我们使用IOscope在MongoDB和Cassandra上展示了用例实验。 MongoDB实验得出的结果进一步证明了我们的假设超出了高级评估范围。 IOscope能够报告由于执行的工作负载而导致MongoDB性能差异背后的主要原因。由于顺序之间的意外不匹配而引发此问题磁盘上分配的数据，以及在分布式实验中MongoDB使用的遍历计划。此外，IOscope能够确认在HDD和SSD上发生了该问题。基于IOscope提供的见解，我们提出了一个临时解决方案，通过重写分片数据来解决该问题。这允许获得有关实验的新线性和可扩展结果。