延迟是描述存储性能时最重要的指标之一，因为它指的是存储设备响应数据请求所需的时间. 更低的延迟等于更快地访问数据，可以显著影响应用程序的性能并改善用户体验. 影响延迟的因素包括各种硬件组件, network stack, workload characteristics, storage architecture, and software stack.

RocksDB是一个以存储为中心的键值数据库，是Meta许多操作的支柱. Here’s their description from RocksDB.org:

RocksDB建立在LevelDB的基础上，可以在拥有多个CPU内核的服务器上运行, to efficiently use fast storage, to support IO-bound, in-memory and write-once workloads, 并且灵活地允许创新.” 

The goal of the Yahoo! Cloud Serving Benchmark (YCSB)项目是开发一个框架和一组通用的工作负载，用于评估不同的“键值”和“云”服务存储的性能. 该项目包括两个主要部分: 

• YCSB客户端:一个可扩展的工作负载生成器 
• 核心工作负载:由生成器执行的一组工作负载场景 

当运行RocksDB YCSB读取繁重的工作负载时，我们多次看到大的延迟峰值. 读取延迟预计小于5ms(与之前的运行一致), but after running back-to-back runs, 我们开始看到大约113毫秒的大延迟. 为了模拟这个问题，我们使用了FIO并能够复制它. FIO中观察到的最大延迟为18ms, 而与RocksDB中观察到的延迟不同, is still higher than the expected value.



In the case of FIO, 我们查看了一个作业文件的事务日志，发现在一段特定的时间内没有任何事情发生, which is equivalent to the latency seen. However, when we look at the NVMe™ driver layer, 任何事务的延迟都不会接近18ms, 所以我们知道延迟的来源一定是应用程序.

延迟偏移不是驱动器的问题，而可能是它上面的层的行为.

• 即使是像FIO这样简单的工具也会遇到导致报告高延迟的系统影响. 
• 系统上的噪声会影响FIO中的最大延迟报告 
  • 7 × 9的QoS延迟看起来是一致的. 

block层的RocksDB延迟为113ms，由BPF跟踪脚本测量. Bpftrace 是一个Linux的跟踪框架，允许用户在运行时跟踪和分析系统的各个方面. We referred to BIO snoop script from Brendan Gregg’s Performance Tools 它输出每个存储设备I/O的细节与延迟，并寻找时间顺序模式.

It uses kprobes (kernel probes), 一种用于动态跟踪的Linux内核机制，它允许用户在几乎任何内核函数中插入断点, 调用处理程序，然后继续执行.

To debug the root cause, 我们收集了各种统计数据来了解高延迟的来源.

• IO stat
  • 设备和分区的系统输入/输出统计信息
  • Measured at the kernel layer

• 总线分析器-捕获和分析在PCIe总线上传输的数据
  • 个人交易信息——如交易类型、地址、数据有效载荷 
  • Shows the signal timing

• OCP latency monitor  
  • 在硬件和固件层进行测量. 

In conclusion, 观察到的高延迟是在系统堆栈上，因为内核层上的延迟都不是, PCIe bus, 硬件和固件层都不接近工作负载跟踪中看到的延迟峰值.