极致优化SSD并行读调度

作者 | GL

导读

提升广告检索漏斗一致性，要求在粗排阶段引入更丰富的信号，这些信号的需求量已经远远超出了内存的承受能力。为此，我们考虑引入基于NVMe SSD的分层存储。本文详细探讨了一种长尾可控的方法论，以及在这个方法论的约束下，如何极致优化读调度。这些方法对于实施类似LargerThanMem的技术也将提供有价值的启发。

01业务背景

业务需要更大存储空间，需求量预期远超过内存可承受。举例来说，客户落地页是客户营销内容的核心阵地，增强对客户落地页内容特征理解，才能实现用户兴趣和客户投放的精准匹配，提升用户体验和转化率，凤巢正排服务引入 URL 明文是关键一步。凤巢正排服务检索查询完全基于内存，内存存储着亿级别广告物料和检索线程需要的上下文。凤巢正排服务实例上万，单实例内存 Quota 已高达云原生红线，常态利用率 85+%，URL 明文引入后，即使业务上极致去重压缩，单实例还需增加数十GB，预期随广告库会继续增长，内存已远远不够。

广告检索过程引入基于 NVMe SSD 的分级存储，长尾控制尤其关键。检索效果对处理性能极为敏感，若查询超时导致检索 KPI 失效，将可能造成广告丢失，从而带来收入损失。以凤巢正排服务来看，单 PV 召回广告创意量在万级别，正排服务通过多分库分包实现并行，即使在单个包内，广告创意数量也可达数百。从检索系统的算力分配来看，针对百条 URL 明文的查询，其长尾性能空间仅为 5ms。

02技术背景

SSD 作为内存存储扩展，缺点是读写干扰不可控。SSD[1] 的操作要求必须按页进行读写，否则会导致读写放大效应。此外，SSD 硬件特性还要求“擦除后写”，因此写数据会额外引起数据搬运损耗和擦除损耗，而擦除操作的耗时往往是读操作时间的 1000 倍！更令人担忧的是，对于那些需要极低随机读取的业务而言，SSD 就像一个无法调节的『黑匣子』，应用无法直接干预由读写干扰带来的查询长尾问题。

业界常用访盘优化手段，未能控制读长尾。业界常用软件写盘优化，确实可以显著提升吞吐，但对长尾控制力度有限，主要手段是：① 把随机写转化为对齐写、顺序写，② 整文件大块删除，③ 流量低峰期触发盘 GC。比如论文 FAST' 15《F2FS: A New File System for Flash Storage》[2] 介绍了一种面向 SSD 的全新文件系统F2FS，基于 Log-Structured File System 的技术，将所有的写入操作转换为日志记录，从而减少写放大效应，并提高了写入吞吐。下图中展示 F2FS v.s. ext4 在随机写场景（varmail、oltp）获得吞吐优势：

△F2FS: A New File System for Flash Storage》 图4

业界涌现出新硬件控制读长尾。硬件标准如 OpenChannel[3,4]，在块存储之外还额外提供了接口，使得业务可以更加精细地控制数据位置和命令调度，从而结合业务特点，在一定程度上实现了读写隔离，进而控制了长尾效应。曾经，Linux LightNVM[5] 试图标准化对 OpenChannel 的操作，但由于难以定义合理且简单的块操作接口，最终被放弃，这也催生了 Zoned Namespace SSD（ZNS）[6] 新的硬件标准。ZNS 硬件并不是传统的块存储，而是一种称为 Zone 存储的概念。整个固态硬盘被划分为多个等长的区域，称为 Zone。Zone 内的数据必须以顺序的页对齐方式进行写入，并且在进行 Zone 内数据复写之前，需要对整个 Zone 进行 reset 操作。ZNS 硬件层面，也按 Zone 接口做了擦除单元隔离。

△《ZNS: Avoiding the Block Interface Tax for Flash-based SSDs》图5

新硬件的引入和打磨需要较长的周期，短期的业务需求亟需满足。从长远来看，ZNS 固态硬盘是未来的发展趋势，我们也已经和基础架构团队共同探索。然而，在当前情况下，我们需要充分利用现有的检索池中的 Nvme 存储。为此，我们发起了 Ecomm Uniform SSD Layer - SsdEngine 项目，其目标是在底层集成各种硬件（包括 NVMe、ZNS），在上层根据典型的商业业务场景封装接口，让商业业务最大限度用上硬件发展和软硬件结合的技术红利。

△SsdEngine整体架构

通用场景 NVMe 长尾完全不可控，检索特化场景长尾可控。Nvme SSD 在实际应用中确实受到多种读写干扰因素的影响，其主要因素包括读写单元大小（ValueSize）、读写频次（IOPS）、数据生命周期一致性（Lifetime）等等。这些影响因素的作用是复杂的，且无法简单地通过公式化加以描述 [7]。然而，检索业务也有应用特殊性：检索业务属于重读轻写的场景，在满足足够吞吐用于回溯止损的前提下，我们甚至愿意在一定程度上牺牲一部分写吞吐，以换取更为稳定的读性能。基于这一背景，结合检索业务的独特特点，我们采用了硬件友好的磁盘访问模式（Disk Access Pattern），并设计了一套基准测试（Benchmark）方案，以此来进行系统性能评测。在评测中，我们针对占检索池大头的数种 NVMe 盘型号进行了测试，最终得出以下结论：通过控制读单元大小（ValueSize = 4K）以及调整读写吞吐比（IOPS Pattern），能够有效操控读写影响，从而实现对读操作长尾的控制。下图是对于Intel P3600 盘，在读 999per 5ms 的情况下，物理盘最佳“读写配比”。

△Intel P3600 读长尾可控的读写配比

混布环境下控制单盘 IOPS 是涉及多层次的复杂问题，本文只分享单实例实践。在单个实例中，要严格控制读写吞吐，就要从默认的基于 PageCache 的读写模式，转换为使用 Direct I/O（以下简称 DIO）模式，以便获取硬件级别的读写控制权。操作系统将数据存储在 PageCache 中，以供后续的 I/O 操作直接从内存中读取或写入，从而显著提高读写性能。在切换到 DIO 读写模式时，为了弥补缺少 PageCache 的性能影响，我们引入了 Libaio/IoUring 异步访问机制，充分发挥 SSD 的并行处理能力。下图是随机读 randread 和顺序读 read 混合的评测，如果纯顺序读，那么 PageCache 吞吐可达 1+G，且具备性能优势，为此我们也进一步做了页缓存的工作，此处先按下不表。

△单机吞吐评测数据

03解决方案

3.1集成 Libaio

Linux Libaio 的操作接口和工作原理十分直观。常规操作接口分三步：

（1）通过 io_prepare 准备异步请求。

（2）io_submit 发送一批请求。

（3） io_getevents 采用 polling 的方式等待所有请求结束。

工作原理层面，io_submit 将所有请求都提交给了 IO 调度器，IO 调度器做完合并、排序类调度优化后，通过对应的设备驱动程序提交给具体的设备。经过一段时间，读请求被设备处理完成，CPU 将收到中断信号，设备驱动程序注册的处理函数将在中断上下文中被调用，调用 end_request 函数来结束这次请求，将 IO 请求的处理结果填回对应的 io_event 中，唤醒 io_getevents。

△Libaio 接口示例

SsdEngine 集成 Libaio 的方式也非常直观。

（1）初始化 IO 任务队列大小为 iodepth。

（2）批量设置 nr 个 IO 任务的读参数，包含文件的句柄、大小、偏移量。

（3）一次性提交 nr 个 IO 任务的读请求。

（4）针对提交的 IO 任务，我们采用分批次等待的方法，设置参数 min_wait_nr 和 batch_timeout，其中 min_wait_nr 的值为 min(nr >> 2, nr - completed) ，作用是减少 io_getevents 系统调用损耗，并实现 IO 任务与后续 CPU 任务的并行化。batch_timeout 会配合整体 timeout，控制整体超长耗时。

// 初始化 Libaio 队列
io_queue_init(iodepth, context)


// 设置 nr 个 IO 任务的读参数
for (int i = 0; i < nr; i++) {
    io_prep_pread(iocb_list[i], fd, page[i], page_size[i], page_offset[i]);
}


// 提交 nr 个 IO 任务
io_submit(context, nr, iocb_list /*start*/);


// 分批次等待，设置最小等待个数 min_wait_nr，最大等待个数 max_nr - completed，以及超时 ts
while (completed < nr) {
    int res = io_getevents(context, min_wait_nr, max_nr - completed/*nr*/, events, &ts);
    // IO 任务正确性校验
    for (int = 0; i < res; i++) {
        assert(events[i] == page_size[index]);
    }
    completed += res;
    if (total_time_cost > pv_timeout) {
        io_cancel();
    }
}

3.2 初步集成 IoUring

IoUring 执行过程和 Libaio 大同小异，但更高性能。IoUring 通过实现两个 Ring 结构，将其映射到用户空间并与内核共享，以降低元数据复制和系统调用开销。Submission Ring 包含应用程序发出的 I/O 请求。Completion ring 包含已完成的 I/O 请求的结果。应用程序可以通过更新 Ring 的头/尾指针来插入和检索 I/O 请求，而不需要使用系统调用。总结来说，IoUring 之所以比 Libaio 的性能更优，主要有以下三点：

1、系统调用少：Libaio 在设计上每次 IO 操作需要两个系统调用，IoUring 仅在 IO 任务提交时有系统调用，等待 IO 任务完成则不需要，比 Libaio 少一次系统调用。

2、数据复制：Libaio 存在元数据的复制，IoUring 通过用户空间和内核共享，则不需要数据复制。

3、数据中断：Libaio 依赖基于数据中断的完成通知，IoUring 在 polling 模式下不依赖硬件中断；使用 polling 需要使用内核线程 kthread，我们是混部环境，该方式不采用。

△IoUring 实现原理

SsdEngine 集成 IoUring 的过程却经历了一番探索。我们希望使用和 Libaio 同一语义的接口 io_uring_wait_cqes，IoUring Manual[14] 中解释了该函数的核心参数为，最小等待 IO 任务数 wait_nr 和等待超时 timeout，但是对 timeout 发生时，已经完成多少个 IO 任务，以及对已完成 IO 任务的处理方式没有做过多的介绍。我们先尝试参考 Libaio 同语义接口和参数，假设返回的 IO 任务都在 cqe 队列中直到 nullptr，又尝试了作者在 issue[15] 中的回答，使用宏 io_uring_for_each_cqe 处理已完成的 IO 任务，但都会在任务的结果校验环节发生错误。最终通过对 kernel 5.10 源码的跟踪，我们发现在 io_uring_wait_cqes 函数实现中增加了 io_uring_prep_timeout 超时任务，需要业务单独处理。我们还发现不同版本内核，超时任务处理并不相同。

io_uring_wait_cqes：填入 wait_nr 等待任务数和 ts 超时参数 
1.  __io_uring_submit_timeout(ring, wait_nr, ts);
  该函数的一个重点是，给 sqe 队列添加了一个超时任务：io_uring_prep_timeout，这个任务是管理 wait_nr 和 ts 的关键
2.  __io_uring_get_cqe(ring, cqe_ptr, to_submit, wait_nr, sigmask);
  2.1 _io_uring_get_cqe(ring, cqe_ptr, &data);
      这个函数是最终调用的主要处理逻辑
    2.1.1 __io_uring_peek_cqe(ring, &cqe, &nr_available);
      该函数不阻塞直接获取完成任务的队列 head，并且表明当前队列有 nr_available 个；
      一个观察是在返回值没有 error， cqe 不为 null 时， nr_available 才有含义，因为通过打点，有 cqe 为 null，但 nr_aviailable 不为 0 的情况；
    2.1.2 __sys_io_uring_enter2(ring->enter_ring_fd, data->submit, data->wait_nr, flags, data->arg,data->sz);
      提交 sqe 队列。io_uring_submit 最终调用的也是该函数，使用该接口不需要再显示调用 io_uring_submit！

面向 io_uring_wait_cqes 实现的 kernel 版本自适应编程。总之，我们遇到的问题是在不同内核版本中 io_uring_wait_cqes 的内部实现方式有所不同。具体而言，在 kernel 5.10 及其之前的版本，会在函数实现中新增 io_uring_prep_timeout 任务处理超时，等待超时退出时，用户需要感知并单独处理该超时任务。而在 kernel 5.11 及其之后的版本中，函数实现则不再添加 io_uring_prep_timeout 任务。我们线上使用的内核版本属于前者，因此，在集成 IoUring 时，我们采取添加超时任务标识（LIBURING_UDATA_TIMEOUT）判断的方式来兼容这两个内核版本。在超时退出时，低版本内核生成的超时任务会匹配 LIBURING_UDATA_TIMEOUT 的条件分支，此时我们会跳过对该任务的额外处理。而高版本内核则不会触发这个条件分支。

// 初始化 IoUring 队列
io_uring_queue_init(iodepth, io_uring, 0 /*flags*/);


// 设置 nr 个 IO 任务的读参数
for (int i = 0; i < nr; i++) {
    io_uring_prep_readv(sqe, fd, iovecs[i], 1, page_offset[i]);
}


// 一次性提交任务【debug 之后发现，使用 io_uring_wait_cqes 接口不需要再显示的提交任务】
// - io_uring_submit(io_uring);


// 设置 ts 超时参数， wait_nr 等待任务数限制；该函数的返回，要么等到 wait_nr 个任务结束，要么等待超时
while (completed < nr) {
    io_uring_wait_cqes(_s_p_local_io_uring, &wait_cqe, wait_nr, &ts, nullptr /*sigmask*/);
    io_uring_for_each_cqe(io_uring, head, cqe) {
        // 判断是否为超时 IO 任务
      if (cqe->user_data == LIBURING_UDATA_TIMEOUT) { 
            continue; 
        }
      process(cqe);
        io_uring_cq_advance(io_uring, 1);
        completed++;
    }
}

3.3 自适应切换 Libaio/IoUring

IoUring 有 8% 性能优势。无论是 FIO 压测效果，还是 SsdEngine 集成效果，都能看出在厂内机器环境下，IoUring 较 Libaio 可提升 8% 的吞吐。

SsdEngine 要尽可能使用 IoUring。但 IoUring 依赖内核版本升级，这也是个较长期的过程。为此我们实现了自适应切换并行调度器，在 5 系之下内核的机器上，自动切换为 Libaio，在 5 系之上内核的机器，自动切换为 IoUring，并且优先 IoUring。

if (io_uring_queue_init(env_test_iodepth, &ring, 0) == 0) {
  io_uring_queue_exit(&ring);
  return new(std::nothrow) UringPageScheduler;
} else {
    return new(std::nothrow) AioPageScheduler;
}

3.4流水线设计

在分层存储中，存在两种经典的索引方式：HashKV[8,9] 和 LSM[10]。HashKV 一般是全内存索引，基于哈希函数将键映射到存储位置，因此适用于快速查找，但在范围查询上表现相对较差。相比之下，LSM（Log-Structured Merge）索引采用多层次、顺序写入的方式，适合高吞吐量的写入操作和范围查询，但可能在单个键查找上略显繁琐。对于检索多读少写且点查的场景下，我们采用了 HashKV。

检索过程中，一次请求会有多个 KV 查询操作，引入异步并行 IO 的简易模式是：基于内存串行查询 HashTable 获取 value 存储地址，一次性发起并行访盘 IO 操作，再等待任务结束。

特别说明：

（1）对于跨多页的大 Value，在构造查询任务时候，会拆分为多个按页大小子查询任务。

（2）不足一页按页查询。

（3）一次 PV 中重复页面查询会被去重。

简易查询模式抽象如下图。横轴代表时间线，纵轴从上到下依次为应用层代码的调用顺序，在一次批量查询 IO 任务个数 batch_size 大于并行 IO 队列的大小（iodepth）时，会重复进行调度流程：schedule- 批量（iodepth 个）查询内存中的 HashKV 获取 value 存储地址， pread - 批量（iodepth 个）设置 IO 任务的参数，submit- 批量（iodepth 个）提交 IO 任务进行处理，wait- 根据 min_nr/max_nr 和 timeout 参数分批次等待 IO 任务的完成，在等待 IO 任务的过程中，并行进行这部分的数据校验，直到等到所有（iodepth 个）IO 任务的完成。

△简单查询模式

我们的优化思路是：把当前的串行的 schedule-submit-wait 模式，改为流水线，增加 IO 和 CPU 的处理并行度。具体实现上，分批次提交任务，等待任务的过程中，执行 HashTable 查询。面向用户接口方面，我们额外引入了两个流水线控制参数，这样业务可选择均衡小批量带来的系统调用开销和性能提升：

1、batch_submit，一次性提交的 IO 任务数。默认等于 iodepth，即一次性提交任务。

2、iodepth_low，默认等于 1，流水线跑起来之后，IO 任务队列中低于 iodepth - iodepth_low 个任务的时候，就开始后续任务的填充。

引用流水线后，查询模式抽象见下图。核心变化集中在： submit - 原本攒够 iodepth 个才提交任务，变成攒够 batch_submit 个就提交任务，这使得 IO 任务可以提前进入 wait 状态。wait- 原本等完 iodepth 个任务，变成等待 iodepth_low 个任务。schedule- 查询 HashTable 也因此流水线起来，提升了整体的 IO 任务和 CPU 任务的并行空间（灰色区域）。

△流水线查询模式

3.5流水线效果评测

评测环境

评测均采用单线程运行的进程，运行环境机型是 CPU INTEL Xeon Platinum 8350C 2.6GHZ ，L1d cache: 48K，L1i cache 32K，L2 cache:1280K，L3 cache:49152K，内核是 64 位 5.10 系，编译器是 GCC 8.2，编译优化选项是 -O2。

评测内容

为了充分验证流水线效果，我们评测了两种读盘场景：场景一、海量 KV，大量读盘和 HashTable 查询；场景二、超大 Value，大量读盘，但极少量 HashTable 查询。

场景一、海量KV

设置一次查询 pv 会发起 1024 次 kv，其中 value 大小为 4K，基本对应到 1024 次 HashTable 访存查询和 1024 个访盘 IO 任务。设置 iodepth=512，iodepth_low=1，调整 batch_submit 为 512、256、128、64、32，观察不同参数下，IO 任务的平响（io_us）、99 分位（io_us_99) ，评测数据见下。

△海量 KV 查询耗时

场景二、超大Value

设置一次查询 pv 会发起 20 个 kv 查询，其中 value 大小为 1M，基本对应到 20 次 HashTable 访存查询和 245*20=4900 个访盘 IO 任务。设置 iodepth=512，iodepth_low=1，调整 batch_submit 为 512、256、128、64、32，观察不同参数下，IO 任务的平响（io_us）、99 分位（io_us_99) ，评测数据见下。

△超大 Value 查询耗时

评测结论

以 Libaio 评测数据为例。在海量 KV 场景下，batch_submit=512（iodepth） 时，没有开启流水线，IO 任务平响 4110us，batch_submit=128 时，是开启流水线的最佳平响参数，IO 任务平响 3373us，有 15%+ 的平响优化。在超大 Value 场景下，batch_submit=512 （iodepth）时，没有开启流水线，IO 任务平响 11.5ms， batch_submit=64 时，是开启流水线的最佳平响参数，IO 任务平响 7.7ms，有 30%+ 的平响优化。IoUring 和 Libaio 的评测效果趋势一致。

04应用场景

正如背景中所指出的，引入落地页信号对于用户体验和总体收入都具有积极的影响。然而，在过去迫于凤巢正排服务的内存容量限制，粗排环节仅能使用 64 位的签名 Sign 推导出归一化 URLID，整条计算链路环节过多，带来了一致性方面的问题。经过最近一个季度的努力，通过在凤巢正排服务中引入URL明文，得到了准确的 URLID，我们显著提高了体验评估的 QLQ 准确性，实验组相较对照组提升了10.8pp，业务收入也得到了明显增长。未来，我们还将把落地页信号引入到更多的粗排 Q 中，进一步提升总体收入。

05相关工作

广告基础检索系统的模块，可被视为一种业务特化的内存数据库。我们观察到，在内存数据库领域中出现了类似的发展趋势：在上世纪 90 年代，随着内存成本的降低和容量的增加，内存数据库得到了发展。然而，随着业务存储量的不断增加，内存的限制逐渐显现。进入 2010 年代，LargerThanMem 分支应运而生[11,12,13]，从历届论文看，该分支还比较学术，主要研究两个关键问题：

1、如何引入分层存储，但又避免引入过多的 I/O 开销，即研究热/冷执行路径（Hot/Cold Execution Path）。

2、在分层存储后，如何设计自适应的冷热数据淘汰和检索策略。

问题 1 是系统设计的技术问题，而当前的 SsdEngine 设计主要关注了这一问题，我们在缓存、调度和访盘等方面都有明确的规划和实现。在广告检索业务中，冷热数据的分布特性明显存在。当前，我们只针对广告库的场景，通过商业广告同步系统的旁路实现，实现了业务分层。未来，在词表场景中，我们还将探索问题 2 的解决方案。

长尾控制在某些特定生产环境中才会成为一个突出问题，我们可以将其视为 LargerThanMem 在广告检索中所特有的挑战。如上所述，在混合部署的环境中，对单盘的 IOPS 进行控制是一个涉及多个层次的复杂任务。广告基础检索服务的特点是写少读多且具备稳定量化的局部性，单实例频控 + 超时控制，已足够控制读长尾。但随着 SsdEngine 进一步推广应用，包括单盘的 Adhoc 组网通信以及集群按照 IOPS 分配，也需要应用起来。

审核编辑：汤梓红