基础设施助力双11（七）：软硬件深度优化，让存储IO如丝般顺滑

导读

众所周知，双11的稳定依赖于坚如磐石的系统，包括软件以及硬件，只有在软硬件都可靠的前提下，才可能保证流畅的用户体验。所以我们必须做到两手抓且两手都要硬才行，以下就让我们来看一个双11中软硬件深度结合优化的真实案例。

业务面临的挑战

某业务在使用某型号搭配新型NVME SSD的服务器过程中发现IO抖动问题，IO抖动造成了业务抖动，严重影响业务性能稳定性。

业务不仅关注NVME SSD本身的读写延时、IOPS，而且需要保证所有IO的延时、IOPS要保持稳定，不能剧烈抖动。

如下图所示，随着时间的变化，TPS的值发生剧跌抖动。我们需要将TPS和延时变得平滑、稳定，而不能发生剧烈抖动，保证业务QoS。

IO抖动根因

为了复现抖动问题，我们使用FIO工具进行压力测试。在测试过程中，增加了文件删除动作，进而发现了更严重的抖动问题 ： IO带宽异常跌0。IO带宽异常跌0对业务来说，是隐藏的一个巨大风险。

下图是OS上删除满盘文件后的FIO性能测试数据，前2小时性能衰退明显。

以下是NVME SSD带宽异常跌0时的IOSTAT的数据。

为了定位和解决该问题，我们需要分析清楚NVME IO带宽跌0时系统处于何种状态：是NVME处理IO超时？还是卡在其他内核某个位置？ 即跌0时是哪种状态：

1）NVME SSD状态 ；

    2）LVM状态 ；

    3）FIO测试进程状态。

    
           

为了准确获取系统状态信息，我们编写了内核模块，成功抓取到写带宽跌0时，LVM设备、NVME设备、FIO进程等多个状态信息。

根据抓到跌0时的状态信息，我们分析了FIO整个写流程，发现内核代码中，NVME驱动和LVM驱动并未直接使用Linux内核的通用块设备层，也就是无法使用通用块设备层的IO拥塞控制功能，并且自己并未实现IO拥塞控制。

内核中，LVM和NVME驱动没有IO拥塞控制，导致块设备请求队列上的IO请求数量无限制增大。而文件系统的Journal/Metadata和Data混在一起，都平等地排在块设备请求队列上，驱动将所有数据一起回写到SSD上，造成累积的IO请求数量过多，进而导致Journal数据回写时间不可预期。

同步写要求Journal+Data同时完成，只有当前面的Journal写完成之后，才能进行下一步IO写。而Journal数据回写时间不可预期，就会引起阻塞后续IO写，进而写带宽异常抖动。

LVM和NVME驱动均不经过Linux内核通用块设备层（有IO拥塞控制功能），且自己未实现IO拥塞控制，于是出现IO异常跌0或异常抖动。

软硬件深度结合

在NVME驱动中实现了IO拥塞控制功能，可以解决软件层面引起的抖动问题，但我们发现因为NVME SSD硬件本身内部存在GC（Garbage Collection，垃圾回收）机制，同样还是会引起IO的剧烈抖动，所以在大压力场景下，仅优化NVME驱动（软件层面）仍然不能够满足业务的QoS要求，这就要求我们必须要考虑软硬件深度结合来进行优化。

在确认了SSD本身的抖动主要是由于内部GC导致之后，我们调整了OP（Over-provisioning，预留空间），再测试，下图是软硬件深度优化后的TPS和RT性能数据。

由上可见，我们通过增加NVME驱动IO拥塞控制 + 调整SSD OP，进行了软硬件深度结合的优化，从而保证该业务在双11最终实现了IO处理上的丝般顺滑，助力了基础设施对双11坚如磐石的保障。

我们还会在软硬件结合优化的道路上持续走下去，从而保证基础设施具备更强的可用性和可靠性！