Linux io_uring 多队列提交怎么核对：SQPOLL、提交批次与空转 CPU 边界

线上文件服务把单个 io_uring ring 拆成多个 worker 后，延迟曲线并没有按预期下降，反而多出几条持续占用 CPU 的线程。问题通常不在“队列越多越快”，而在于 SQPOLL 把提交成本换成了内核轮询成本：提交很密集时值得，队列经常空闲时就可能只剩空转。

SQPOLL 到底替换了哪一段提交路径

普通 io_uring 程序先把 SQE 放进共享提交队列，再通过 io_uring_enter 通知内核。启用 IORING_SETUP_SQPOLL 后，内核会创建一个轮询线程观察提交队列；用户态填好 SQE 后，很多场景不必为每批请求单独陷入内核。

这里的关键不是“完全没有系统调用”。轮询线程进入休眠后，应用仍要通过唤醒路径让它重新工作。man-pages 对 sq_thread_idle 的描述也说明了这一点：超过空闲阈值后，内核会设置 IORING_SQ_NEED_WAKEUP，应用需要调用提交接口唤醒它。

多队列程序先看三个可观测量

不要一上来调大 ring entries。先把每个 ring 的提交批次、轮询线程和工作间隔记下来。下面这张表可以作为压测记录的最小字段集。

在 Linux 主机上可以先用 ps -L -p $PID -o pid,tid,psr,pcpu,comm 查看线程分布，再用 pidstat -t -p $PID 1 连续观察。单次快照只能说明“此刻有线程”，不能证明它一直在忙。

sq_thread_idle 和提交批次怎么一起调

sq_thread_idle 是毫秒值。设置得很小，空闲 ring 更快睡眠，但突发请求可能先承担一次唤醒；设置得很大，突发延迟更平滑，却会让低负载 worker 长时间轮询。可以先从 1000 或 2000 毫秒做基线，再根据工作间隔缩短，而不是直接设为永不休眠。

struct io_uring_params params = {
    .flags = IORING_SETUP_SQPOLL,
    .sq_thread_idle = 1000,
};

int ret = io_uring_queue_init_params(256, &ring, ¶ms);
if (ret 

批次也要一起看。每次只提交一个 SQE 时，SQPOLL 的收益很容易被任务准备、CQE 消费和线程调度抵消；把多个独立请求组成小批次，通常比盲目增加 ring 数更容易测出差异。

一次可复现的对照压测应该怎么设计

至少准备两组配置：普通 ring 和 SQPOLL ring。保持文件、请求大小、worker 数、完成处理方式不变，只切换 ring 初始化参数。压测时分别记录吞吐、提交延迟、P99、进程 CPU 和轮询线程 CPU。

1. 先用固定并发跑 60 秒预热，避免把首次打开文件等成本混进结果。
2. 再分别测试连续提交、每 5 毫秒一批、每 50 毫秒一批三种间隔。
3. 把提交批次固定为 1、8、32，观察系统调用减少是否真的传导到 P99。
4. 最后降低并发，确认低负载下的 CPU 代价是否超过延迟收益。

如果连续提交场景只提升吞吐但 P99 不变，不要把它写成“延迟优化”；如果低负载下 CPU 明显升高，也不要用平均吞吐掩盖这个成本。生产配置更应该选择符合业务间隔的那一组。

常见坑：多队列并不等于多倍收益

每个 worker 都启用 SQPOLL，会不会创建很多轮询线程？

会。创建多少个 ring、是否通过工作队列共享资源，都要和 worker 数一起核对。线程数增长后，CPU 亲和性、容器配额和调度噪声都会影响结论。

看到 SQ_NEED_WAKEUP 就说明 SQPOLL 失效了吗？

不是。它表示轮询线程已经空闲到需要唤醒，应用走一次唤醒路径即可继续提交。真正要看的是唤醒频率、唤醒后的提交批次和延迟变化。

sq_thread_idle 设为 0 一定最快吗？

不一定。持续轮询更适合高密度提交；低负载服务可能只得到更高 CPU 占用。这个参数必须和真实请求间隔、CPU 配额一起压测。

把采用边界写进配置和回滚方案

上线前保留普通 ring 的开关，至少让启动参数可以在不改业务代码的情况下切换。监控里同时放提交批次、轮询线程 CPU、P99 和唤醒次数，任何一项单独变好都不足以证明方案成立。

如果 CPU 配额不足或请求间隔变稀，先降低 sq_thread_idle，再考虑关闭 SQPOLL；如果主要瓶颈在 CQE 消费、磁盘设备或锁竞争，继续优化提交路径不会解决根因。

延伸问答

io_uring 的 SQPOLL 适合所有异步文件服务吗？

不适合。提交密集、系统调用占比高且有稳定 CPU 预算的服务更可能受益，间歇性任务需要谨慎。

如何判断是提交瓶颈还是完成处理瓶颈？

分别记录 submit 到入队、入队到 CQE、CQE 到业务回调的耗时；只有第一段明显占比高，SQPOLL 才有针对性。

生产上应该优先调 ring 大小还是 SQPOLL？

先用对照压测确认队列是否满和提交是否成瓶颈，再决定参数；ring 大小解决容量问题，SQPOLL 解决提交通知路径，不能互相替代。

小结

SQPOLL 的价值是把提交通知交给内核轮询线程处理，代价是线程和空闲轮询的 CPU 预算。多队列场景下，最可靠的验收方法是固定业务负载，分别对照提交批次、唤醒状态、P99 和 CPU，再把结果写进可回滚的配置，而不是只看一项吞吐数字。