队列连接生产者与消费者，也把处理能力不足转化为等待；并发增加可能提高吞吐，也可能只扩大在途状态与超时风险。

请求经过多种队列

应用线程池、锁等待、套接字、块层、驱动和设备内部可能分别排队。一层队列增长会向其他层传播影响，但不能由一个总延迟直接定位。

Linux blk-mq 描述块 I/O 多队列组织。应用并发数、块层在途请求数和设备队列深度不是相同量；同步接口或不同 I/O 引擎还会改变可达到的并行度。

请求到达 -> 应用等待 -> 提交等待 -> 设备执行 -> 完成处理 -> 返回
               |            |           |            |
             排队点       排队点       服务点       排队点

“设备快”只覆盖其中一段，不能保证整个响应快。

吞吐与延迟共同描述系统

吞吐表达单位时间完成多少工作，响应时间表达一个请求从入口到出口耗时。服务时间通常只覆盖某个处理阶段。不同工具测量的起止点不一致，名字都叫 latency 也不能直接比较。

稳定、边界一致的平均系统可用 Little 定律进行一致性检查：平均在途数 L、平均完成率 λ 和平均停留时间 W 满足 L = λW。原创推导例：若某明确边界内平均完成率为 1000 次/秒，平均停留时间为 0.01 秒，则平均在途约为 10。它不是配置队列深度建议，也不能直接套在增长中的不稳定积压上。

尾延迟不是平均值的装饰

少量特别慢的请求可能决定用户体验、超时和重试。平均值正常，不代表 p99 正常；不同时间段的分位数也不能直接取平均得到整体分位数。

原创场景：大部分请求命中缓存，小部分触发存储与同步等待。平均值被快请求拉低，但慢请求仍影响交易超时。解释需要连接请求类别和具体路径，而不是仅给出一个分位数。

增加并发为何可能反效果

系统尚有可重叠工作时，并发可能提高完成率；某阶段稳定能力用尽后，更高并发可能主要增加排队、缓冲区和资源竞争。失败后的无界重试又可能放大到达率，形成正反馈。

因此并发上限既是性能参数，也是内存预算和故障控制的一部分。每请求状态乘以在途量，有助于解释负载增加时的内存变化，但不能替代极端输入与共享缓存分析。

资源压力与时间证据

Linux PSI 提供资源争用停顿信息。它帮助区分忙于完成工作与因资源而停顿，但不能独自确定具体硬件故障。

CPU 配额还可能使线程等待可执行额度，详见 cgroup v2。主机空闲与服务被限额可以同时成立。

测试时的边界错配

某工具配置 iodepth，不代表所有引擎和参数都实际产生相同深度；多个作业还会改变总并发。fio 的相关定义见 官方文档。比较应记录实际达到的深度分布，而不是只抄命令参数。

能够成立的结论

“增加并发使该负载的吞吐达到平台区间，并同时增加尾延迟”是有边界结论。“并发越多越快”不是。验收阈值应来自业务目标和约定环境，不应由一次跑分反向生成。

服务器知识库 · 系统架构 · 数据路径 · 测试验收 · 工程参考

公开资料核对：2026-10-07。文档类型：Explanation。逻辑图、场景推演与报告模板为原创，不代表实测结果、厂商内部设计或公司制度；操作仅限获授权的目标和环境。