zStorage 分布式存储系统的性能分析方法

注：本文内容引用自张洋老师的知乎文章，他是一位存储研发专家。

前言

自从加入 zStorage 分布式存储团队以来，性能调优工作一直是我的工作重点之一。从刚开始专注于本地存储（localstore）的性能调优，到后来负责整个 zStorage 分布式存储系统的性能调优工作，zStorage 的性能水平也逐步提升到了一个领先水平。在我之前的文章中，有介绍性能调优的一些方法。在性能调优的过程中，我也逐渐积累了一些分布式存储系统性能分析的方法。当然，这些方法主要是针对 zStorage 的，对其他存储系统或者软件系统应该有一些借鉴意义。本文不打算讨论如何提升性能，主要讨论如何找到性能问题、如何找到性能瓶颈。

硬件性能评测

对于 zStorage 来讲，影响性能的最主要的几个硬件是：CPU、内存、网络和硬盘。在传统的网络设备和硬盘设备上，一般认为网络和硬盘是主要的性能瓶颈；相反，CPU 和内存的性能相比之下要高出几个数量级，不会成为瓶颈。然而，近年来高速 NVMe SSD 硬盘和高速 RDMA 网卡迅猛发展，其性能提升速度远高于 CPU 和内存。很难想象，网络和硬盘的响应时间已经小于 10 μs 级别，并且网络和硬盘的性能还在不断提升。如果说在 10 ms 级别时，与 CPU 和内存相比存在数量级的性能差异，这没有问题。但是来到 10 μs 级别时，CPU 和内存的耗时已经不可忽视。一次内存访问也在 100 ns 级别，而一次 IO 请求经过的代码路径上可能会访问成百上千次内存，这个耗时不容忽视，甚至已经大于了网络的传输时间，甚至也大于了硬盘的响应时间。

所以，在这种情况下，CPU、内存、网络和硬盘的性能都需要评估。特别是内存、网络和硬盘都可能成为瓶颈。目前来看，CPU 相比内存的性能还是要高出几个数量级。此外，在 CPU 和内存之间还有 L1、L2、L3 这三级缓存。因此，在做性能分析时，CPU 和内存需要结合起来看。CPU 一般不会成为主要瓶颈，关注点还是在内存的带宽以及 CPU 缓存的命中率上。当内存通道较少（内存条数量不足）或者跨 NUMA 节点访问内存时，内存可能成为瓶颈；当网卡降级，或者网卡带宽较低时，网卡可能成为瓶颈；当硬盘的带宽或 IOPS 数据较差，或者硬盘数量较少时，硬盘可能成为瓶颈。

所以，要确定存储系统的瓶颈在哪里，我们可以在性能符合预期的实验室环境中，对这几个主要部件进行性能评测，形成一个硬件的基准性能数据。例如，针对 zStorage，我编写了一个性能测试脚本，其输出结果大致如下：

在这个评测结果中，对 CPU、Memory、Disk、Network 分别进行测试并打分，然后检测哪个组件是瓶颈，并评估 zStorage 在这样的硬件评分下大致可以跑到什么样的 IOPS。最后，还给出了各个组件的测试数据。有了这样一个基准数据后，在一套新的硬件环境上，不需要实际分析 zStorage 软件本身的问题，可以先进行同样的硬件评分，大致判断出哪个组件是性能瓶颈。

工具法：IO排队，时延分析

在 zStorage 的性能问题定位中，用得最多的一个工具是 ztrace。这个工具是 zStorage 自研的 IO 性能跟踪工具，类似于 Linux 的 iostat 工具。如图所示，是 ztrace 某一秒的数据显示，这里只过滤了 lstore\_6 点位（即 localstore 与 SPDK blobstore 交互的地方，是 localstore 代码的边界，这个点位可以大致判断硬盘的性能情况）。

定位硬盘瓶颈

lstore\_6 点位仅仅是众多点位之一，还有许多其他点位，涉及到 Raft 的 append 和 apply 以及网络传输耗时等。

如图所示，lstore\_6 点位按线程分别统计，zStorage 每个线程独占运行在一个 CPU 核心上。可以看到，每个线程分别统计了 IOPS、带宽、平均时延、最大时延、时延分布、IFIO（排队和正在处理的 IO）以及 IFIO 的数量分布。通过这些统计数据，可以反映出性能瓶颈在哪个模块，也可以直接或间接反映出性能瓶颈在哪个硬件（CPU、内存、网络、硬盘）上。

比如说，我们想知道硬盘是不是瓶颈，可以从以下几个方面来分析：

1）线程间的 IOPS 看起来都比较均衡，都在 4.5w - 4.6w IOPS 之间，这个符合预期，没啥问题；2）这一时刻，IFIO 也比较低，最多的线程仅有 6 个，最少的线程为 0 个；3）从时延上看，IO 响应的平均时延仅为 40 μs+，假如 IO 全流程时延为 300 μs，那么这个占比是很低的；4）再看 IFIO 的分布，观察 IFIO=0 这一列，各个线程都在 20% 左右，表明有 20% 的时间硬盘上没有下发 IO，硬盘的使用率在这一秒仅为 80%；5）还可以结合经验，比如从经验上看，硬盘的时延应该在 30 μs - 60 μs 之间。做性能分析的工程师应该对各个环节的时延大致心里有数。

从以上 5 点可以看出，硬盘不是瓶颈。

定位CPU、内存瓶颈

同样的道理，可以分析出性能瓶颈是否在网络上。如果我们排除了硬盘和网络的瓶颈，剩下的就只有 CPU 和内存了。要确认是否是 CPU 和内存的瓶颈，我会找两个点位，这两个点位之间只有执行代码流程，没有网络、硬盘、系统调用、锁、sleep 等操作。

以下图这样一个简单的模型来说明问题：整个黑色曲线是一个 IO 路径的全部耗时，其中 B0 到 B1 是模块 B 的耗时，A0 到 A1 是模块 A 的耗时，而模块 A 的耗时包含了模块 B 的耗时。真正属于模块 A 的消耗时间为 A0B0 + A1B1 = TA。

由于 TA 是纯粹的代码耗时，这个耗时与 CPU 和内存的性能强相关。如果 TA 的耗时为 100 μs，远大于硬盘的耗时 40 μs，那么可以认为 CPU 或内存存在瓶颈。我在一个实际的现场项目中，曾以这种方式定位过一个问题，最后发现是因为内存条数量不满足要求。实际只安装了一根内存条，而配置清单上写的是 8 根。因此，当时没有先实际检查硬件配置，而是通过这样的时延分析方法，确定了问题方向为内存。

perf工具

另一个高频应用于性能分析的工具是 perf。perf 工具可以细致地分析各个函数的 CPU 占比、缓存未命中百分比、分支预测失败百分比，以及 IPC（每个时钟周期执行的指令数）等性能指标。

这里着重讨论如何定位性能瓶颈。之前我写过一篇文章可以参考：通过 IPC 指标诊断性能问题。

最主要的两个工具是火焰图和 IPC，这两项都可以反映出性能瓶颈所在。

火焰图

由于 zStorage 采用轮询模式，即使没有业务时，CPU 的使用率也是 100%，所以 CPU 使用率无法体现业务的繁忙程度。不过，从火焰图却可以看出业务的繁忙程度。图中绿色框起来的部分是 poller 空转，没有运行实际的业务代码。这直接说明 CPU 和内存目前不是瓶颈。要么是 IO 压力不足，要么是 IO 全部卡在网络和硬盘上未返回。

然后，可以继续通过火焰图分析网络和硬盘的问题：图中左侧的山峰表示硬盘部分，看起来是一座很小的山，可以大致确认硬盘上的压力不大，否则硬盘相关的 poller 会有更多的 CPU 消耗；右侧的山峰表示网络部分，展示了从网络收到 IO 后的处理流程，可见其比硬盘的山要宽、要高。不过，就这张图来看，无法完全确定是 IO 压力小，还是 IO 卡在了网卡或硬盘上。还需要结合上述时延分析法，观察网络和硬盘的时延，才能确认具体情况。