【SPDK 用户态存储】排障坐标系：绑盘、空转、队列满、传输超时与多路径
内容提要
本文介绍SPDK用户态存储栈排障方法，提出五轴坐标系：环境绑盘、Reactor CPU、bdev队列、传输超时和多路径。排障时先选轴再动命令，按默认顺序核对，每排除一轴记录否证，避免并行瞎改。强调区分正常轮询税与真故障，队列满是背压信号，远端超时先查传输而非固件。五轴方法价值在于强制一次只证伪一轴，并建议将清单剪进门禁，明确角色分工。
延伸解读
五轴排障的核心：一次只证伪一轴
文章强调，排障时不要并行修改多个参数，而应像做实验一样，每次只针对一个轴进行假设、操作、观察信号并记录。这样能明确知道哪一步有效，避免事后无法归因。这种“一次只证伪一轴”的方法论，比盲目尝试更高效，也便于团队协作和知识传承。
区分正常轮询税与真故障
SPDK 采用轮询模型，CPU 占用高是常态，并非故障信号。排障时需结合吞吐量判断：若核满且吞吐符合预期，则是正常的轮询开销；若核满但吞吐近零，则可能是空转或错误路径重试。理解这一区别，可避免误将正常现象当作故障处理。
队列满与远端超时的处理原则
队列满被视为背压信号，应检查提交速率是否超过完成速率，而非简单增加大页。远端超时若本机 bdev 正常，应优先排查传输层（如网络、listener 配置），而不是重装固件。这些原则帮助快速定位问题层级，避免无效操作。
排障清单的工程化落地
文章建议将五轴检查清单剪进门禁，并明确角色分工（如谁负责 RPC 库存、谁有权 reset 统计）。同时，否证记录应保存九十天，便于版本回归分析。这种工程化做法将排障经验固化为流程，提升团队整体效率。
Q&A
SPDK排障时，为什么说“盘已经setup了”和“业务仍超时”可以同时为真？
因为SPDK用户态存储栈中，设备被绑定到用户态驱动（如vfio-pci）后，内核工具（如nvme list）可能看不到设备，但业务超时可能由其他轴（如Reactor CPU、bdev队列、传输超时或多路径）引起，而非设备未绑定。排障应从五轴坐标系出发，而不是仅依赖设备是否可见。
SPDK排障五轴坐标系是哪五轴？默认的核对顺序是什么？
五轴包括：环境绑盘轴、Reactor CPU轴、bdev队列轴、传输超时轴和多路径轴。默认核对顺序为：先环境绑盘轴（设备归属与大页），再进程（RPC socket连接），然后iostat/错误计数定层，若仍像远端问题则检查传输与路径轴。
在SPDK中，Reactor CPU轴高占用但IOPS上不去，可能是什么原因？
可能原因包括：poller空转等待完成、qpair未建好、错误路径狂重试，或者cpumask配置不当、跨NUMA访问、阻塞操作打进reactor。需要区分正常轮询税与真故障，并检查cpumask是否与网卡/NVMe同NUMA。
SPDK中bdev队列满应该如何处理？为什么说“队列满是背压信号”？
队列满表示提交速率超过完成速率，是背压信号，不能通过增加大页解决。应先检查提交速率是否超过完成速率，再排查是否缺核或存在不必要的模块叠层（如aio/raid/lvol）。
当远端initiator报超时，但本机bdev iostat正常时，应该优先检查什么？
应优先检查传输轴和网络，而不是重装NVMe固件。核对listener地址、防火墙、RDMA链路，并使用path iostat查看是否单路径问题。
SPDK多路径轴排障时，如何避免将局部失败误判为整盘故障？
应使用bdev_nvme_get_path_iostat查看路径级统计，避免将活路径与死路径平均成“半死”。同时检查故障切换是否可观测，是否与应用超时耦合。
SPDK排障中，为什么强调“一次只证伪一轴”？
因为并行修改多个参数（如cpumask、MTU、队列深度）会导致无法确定哪项操作有效。通过一次只验证一个轴的假设，可以明确因果关系，提高排障效率。
SPDK排障清单中，为什么建议记录“否证”过程？
记录否证过程可以避免下一班重复检查，支持交接，并帮助识别是否同一轴连续失败需要升级为双人复盘。否证记录应保存九十天，覆盖版本回归窗口。
