延迟是指存储设备响应数据请求所需的时间，它是表征存储性能的最重要指标之一。较低的延迟意味着数据访问速度更快，可显著提升应用性能和改善用户体验。影响延迟的因素包括各种硬件组件、网络堆栈、工作负载特性、存储架构和软件堆栈。
RocksDB 是一个以存储为重点的键值数据库，是 Meta 许多业务的支柱。以下是来自 RocksDB.org 的相关介绍：
“RocksDB 基于 LevelDB 构建，可扩展到在具有多个 CPU 内核的服务器上运行，以高效使用快速存储，支持 IO 密集型、内存中和一次写入工作负载，以实现灵活创新。”
Yahoo! 云服务基准测试 (YCSB) 项目提供了一个框架和通用工作负载集，用于评估不同“键值”和“云”服务存储的性能。该项目主要包括两部分：
- YCSB 客户端：可扩展的工作负载生成器
- 核心工作负载：一组工作负载场景，由负载生成器执行
当在 RocksDB 上运行读取操作频繁的 YCSB 工作负载时，我们多次看到较大的延迟峰值。读取延迟预计小于 5ms（与之前的运行一致），但是在连续运行之后，我们开始看到大约 113ms 的高延迟。为了模拟这个问题，我们使用 FIO 对测试进行了重现。FIO 中观察到的最大延迟为 18ms，虽然与 RocksDB 中观察到的延迟不同，但仍高于期望值。
在使用 FIO 测试时，我们查看了作业文件的事务日志，发现在一段特定的时间内什么都没有发生，这就是我们看到的延迟。但是，当我们查看 NVMe™ 驱动层时，没有任何事务的延迟接近 18ms，由此我们知道，延迟一定源于应用。
延迟偏差不是硬盘问题，而可能是它上面那层的行为。
- 即使是像 FIO 这样简单的工具也会遇到导致报告高延迟的系统影响。
- 系统噪声会影响 FIO 中的最大延迟报告
- 7x9 的服务质量 (QoS) 延迟看起来一致。
RocksDB 的 113ms 延迟来自于块层，由 BPF 跟踪脚本测量得出。Bpftrace 是用于 Linux 操作系统的一个跟踪框架，让用户能在运行时跟踪和分析系统的各个方面。我们参考了 Brendan Gregg 在《Performance Tools》中提供的 BIO snoop 脚本，该脚本可输出每个存储设备 I/O 的延迟细节，并按时间顺序模式显示。
它使用 kprobes（内核探针），这是一种用于动态跟踪的 Linux 内核机制，允许用户在几乎任何内核函数中插入断点，调用处理程序，然后继续执行。
为了调试根本原因，我们收集了各种统计数据，希望了解高延迟的来源。
- IO 统计数据
- 设备和分区的系统输入/输出统计数据
- 在内核层测量
- 总线分析器 - 捕获和分析在 PCIe 总线上传输的数据
- 个别事务信息 – 如事务类型、地址、数据有效载荷
- 显示信号时序
- OCP 延迟监控
- 在硬件层和固件层测量。
综上所述，不管是内核层、PCIe 总线，还是硬件层和固件层，它们的延迟都与在工作负载跟踪中看到的延迟峰值大相径庭，因此，所观察到的高延迟只能是系统堆栈的延迟。
