如何用请求耗时与队列指标排查服务器带宽长期跑不满时的业务访问慢？

带宽曲线长期没有接近网卡或线路上限，并不能证明服务器访问链路没有问题。带宽反映的是单位时间传输了多少数据，而用户感知的“慢”还取决于请求是否在应用线程池、连接池、磁盘、数据库锁或上游依赖处等待。一个请求即使只返回几十 KB，也可能因为排队数秒后才开始发送响应，此时带宽不高，页面仍然明显变慢。

排查这类问题时，应把请求耗时、请求速率、响应大小、各类队列和 CPU、内存、磁盘、网络、数据库指标放在同一个时间窗口内比较。重点不是寻找某个固定阈值，而是确认“哪个指标先发生变化”“哪个队列随后增长”“请求耗时的增加能否由该变化解释”，再通过复测验证判断。

先统一“带宽跑不满”的观察口径

带宽利用率是结果指标，不是业务处理能力指标。服务器只有在有足够多的请求、足够大的响应和足够快的发送能力时，才可能持续接近带宽上限。以下情况都可能导致带宽不高，但访问仍然变慢：

• 请求主要是小型 API、登录、查询和页面 HTML，单次响应体积很小。
• 请求卡在排队、数据库查询或第三方接口调用阶段，尚未进入数据发送阶段。
• 大文件或静态资源命中缓存，业务服务器实际只处理少量动态请求。
• 并发连接数不足，或者应用工作线程、数据库连接池已经耗尽。
• 网络存在丢包、重传、握手或连接建立问题，但有效吞吐没有形成。
• 监控统计的是整台服务器平均带宽，掩盖了某个时间点、某个进程或某个网络方向的异常。
• 用户访问的慢点发生在浏览器、DNS、客户端网络、负载均衡或上游服务，而不是服务器出口带宽。

可以先用一个简单关系判断带宽是否有机会被占满：

业务吞吐量约等于请求速率 × 平均响应字节数 × 8。

例如，平均响应大小为 250 KB，业务请求速率为每秒 80 个，按十进制单位计算：

1. 250 KB = 250,000 字节。
2. 每秒传输字节数 = 250,000 × 80 = 20,000,000 字节。
3. 每秒传输比特数 = 20,000,000 × 8 = 160,000,000 比特。
4. 换算为 Mbps：160,000,000 ÷ 1,000,000 = 160 Mbps。

如果服务器接入的是 1 Gbps 线路，160 Mbps 只相当于约 16%。这并不表示请求处理一定充足；如果每个请求平均耗时 2.5 秒，系统同时挂起的请求可能已经很多。

并发请求数还可以用近似关系理解：

并发请求数 ≈ 每秒请求数 × 平均请求耗时。

上面的 80 个请求每秒，如果平均耗时从 200 毫秒增加到 2.5 秒，并发请求量会从约 16 个增加到约 200 个。即使响应体积没有变化，应用线程、连接池和数据库连接也可能因此排队。

建立统一的观察窗口

不要只打开一张带宽图，然后在不同时间点分别查看 CPU、磁盘和数据库。应先确定一段包含“正常阶段”和“变慢阶段”的时间窗口，再对齐所有指标的时间戳。

观察窗口应包含哪些内容

常见业务可以先选取 10 到 30 分钟的窗口；如果问题只持续几秒，则需要使用秒级或十秒级数据，而不能只看一分钟平均值。至少记录以下内容：

平均耗时不应单独使用。一个接口平均耗时 300 毫秒，可能是全部请求都接近 300 毫秒，也可能是 95% 请求为 50 毫秒、5% 请求超过 5 秒。后者会造成部分用户明显投诉，也可能进一步耗尽线程和连接池。

按请求类型拆分

整站平均值通常不够用，至少应按以下维度拆分：

• URL 或接口类型：查询、写入、上传、下载、登录、静态文件。
• 状态码：成功、客户端错误、服务端错误、超时。
• 响应体积：小响应和大响应不能混合比较。
• 上游依赖：数据库、缓存、内部服务、外部接口。
• 请求来源或入口：不同负载均衡节点、不同应用实例或不同机房入口。
• 时间阶段：正常时段、开始变慢时段、恢复时段。

如果使用 Nginx、网关或应用访问日志，应尽量获得类似以下字段：请求总耗时、上游连接耗时、上游响应耗时、状态码、响应字节数和请求路径。请求总耗时持续升高，而上游响应耗时没有变化，排查方向与两者同时升高时不同。

先看请求耗时和队列是否同步变化

请求耗时是用户侧结果，队列是系统内部的等待证据。两者结合起来，才能判断“慢”是否真的由服务器资源排队造成。

请求耗时增加时，先确认增加的是哪一段

可以把一次请求粗略拆成以下阶段：

1. 客户端或负载均衡建立连接。
2. 请求进入监听队列或网关队列。
3. 应用线程、协程或任务执行器等待处理。
4. 应用访问缓存、数据库或其他上游服务。
5. 应用生成响应并交给内核发送。
6. 客户端接收数据，期间可能发生重传或连接限速。

总耗时增加，不代表每个阶段都变慢。例如：

• upstream_response_time 增加，通常需要关注应用、数据库或上游服务。
• 请求总耗时增加，但上游响应耗时基本不变，可能是入口连接、发送阶段或客户端网络问题。
• 请求进入应用后的排队时间增加，而应用实际执行时间不变，通常指向线程池、协程调度或并发上限。
• P99 大幅增加但 P50 稳定，可能是少量慢查询、锁等待、GC 或网络重传。
• P50、P95、P99 同时增加，且请求队列持续增长，更像是整体处理能力不足。

队列要区分类型

“队列变长”不是一个单一指标。不同队列对应不同瓶颈：

因此，看到“请求队列增加”后，还需要继续问：队列是在网关、应用、连接池、数据库，还是操作系统设备层形成的。

用指标联动区分主要瓶颈

下面的判断不应理解为固定阈值规则。CPU 80%并不一定有问题，CPU 40%也不一定正常；关键在于它是否与请求耗时、对应队列和错误率在同一时间段发生关联。

CPU瓶颈：运行队列和请求处理时间一起增加

CPU 瓶颈通常表现为应用处理时间变长，CPU运行队列或单核压力同步上升。整机 CPU 平均值可能掩盖单线程或单核瓶颈，因此要同时查看单核使用率、进程级 CPU 和调度等待。

典型变化可能是：

这组数据只是用于说明判断关系的模拟示例，不代表某一套实际监控。带宽基本没有变化，但请求队列、P95耗时、单核使用率和运行队列同步升高，CPU或应用计算能力就比“带宽不足”更值得优先排查。

还要排除以下替代解释：

• CPU总使用率高，但请求耗时和应用队列没有增加，可能只是后台任务或日志压缩。
• CPU平均值不高，但某一个工作线程或单核已满，仍然可能是单线程瓶颈。
• 虚拟机 steal 时间升高，表示虚拟化环境中等待宿主机调度，不能简单归为业务代码耗 CPU。
• 运行队列增加但CPU使用率不高，可能是I/O等待、内存压力或进程状态统计方式导致的误判。
• 应用线程数很多，但线程都在锁、数据库或网络调用上等待，此时增加线程未必有帮助。

在Linux服务器上，可以使用非破坏性的系统工具进行初步对照。以下命令需要安装相应的 sysstat 和 procps 工具包：

vmstat 1 5
sar -u 1 5
pidstat -u -p ALL 1 5

如果CPU使用率、运行队列和应用请求耗时在相同时间段上升，再结合进程级热点、代码采样或接口分布，才可以把判断收敛到具体应用模块。

内存瓶颈：内存压力先出现，随后出现回收或I/O等待

内存不足不一定立即表现为带宽变化。应用可能先经历内存分配等待、垃圾回收、页回收和缓存抖动，最终导致请求耗时增长。若发生交换，磁盘读写也可能随之上升，使问题看起来像磁盘瓶颈。

需要同时观察：

• 可用内存和可回收缓存是否持续下降。
• 内存回收、直接回收和缺页是否增加。
• swap in、swap out是否出现或明显增加。
• 内存压力指标是否升高。
• 应用堆使用率、GC暂停、进程RSS是否持续增长。
• 磁盘 await 和队列是否与内存回收同步变化。

典型关联是：内存逐渐紧张，应用GC或页面回收增加，P95和P99先出现尖峰，随后磁盘延迟和请求队列升高。如果只是缓存占用较高，但可用内存稳定、没有明显回收压力，不能仅凭“free很小”判断内存不足。

也要注意容器限制。宿主机还有大量可用内存，并不意味着容器没有达到自身内存上限。容器被限制后，应用可能先被回收、频繁GC或直接触发内存不足，而宿主机面板看起来仍然正常。

磁盘I/O瓶颈：队列、await和业务耗时同时变差

磁盘吞吐没有达到设备标称上限，也可能存在高延迟。小块随机I/O、同步写、数据库日志写入和共享存储请求，常常先表现为单次操作延迟增加，而不是吞吐达到峰值。

重点看以下关系：

• 磁盘队列长度或平均队列 aqu-sz 增加。
• await 或读写延迟增加。
• 设备利用率长期接近饱和，或者在突发时段快速升高。
• 数据库提交耗时、日志写入耗时和应用请求耗时同步增加。
• iowait 增加，但需要确认等待的是哪块设备。
• 请求队列的增长时间与磁盘延迟增长时间一致。

示例：

这时CPU和网络都没有明显异常，而数据库提交、磁盘延迟和请求耗时联动变化，磁盘或存储后端应优先排查。

但 iowait 不能直接等同于“磁盘坏了”。它也可能来自网络存储、文件系统锁、数据库同步策略或某个进程的大量读写。应继续按设备、进程和文件类型拆分：

iostat -xz 1 5
pidstat -d 1 5
df -h

df -h只能帮助确认空间是否耗尽，不能替代延迟和队列指标。若文件系统空间、inode或挂载状态异常，也要单独核对。

网络问题：带宽不高，但丢包、重传或连接队列异常

网络瓶颈并不等于“Mbps达到上限”。网络层还存在包速率、连接建立、队列、错误和重传等限制。

需要同时观察：

• 网卡接收和发送错误。
• 丢包、TCP重传率和连接重传。
• RTT是否在变慢时段上升。
• SYN backlog、accept队列和连接建立失败。
• TX/RX队列丢弃。
• 小包每秒数量是否异常，即PPS是否接近限制。
• 单个网卡、虚拟网卡、负载均衡节点是否出现局部异常。
• 应用实际发送速率是否受客户端读取速度影响。

带宽只有 100 Mbps，但如果RTT明显升高、重传率上升，应用可能因TCP拥塞控制而迟迟发不出完整响应。此时图表显示的是低有效吞吐，而不是链路健康。

可使用以下命令查看基础网络状态：

sar -n DEV,TCP 1 5
ss -s
ss -lnt
ip -s link

如果怀疑连接队列，应结合监听端口对应的服务进程和负载均衡指标确认。不要直接修改内核队列参数来掩盖问题；如果后端应用无法及时接受连接，单纯增大队列只会延后失败，并可能让用户等待更久。

还要排除监控口径问题：

• 查看的是出口带宽，但真正拥塞的是入口方向。
• 查看的是整台宿主机，异常发生在某个虚拟网卡。
• 监控按一分钟采样，短时突发被平均掉。
• 统计的是有效载荷，没有包含协议重传或底层错误。
• 只有部分接口或部分来源访问慢，整机平均值因此不明显。

应用瓶颈：工作队列增长，但底层资源未必饱和

如果CPU、内存、磁盘和网络都没有明显异常，而应用请求队列和响应时间持续增加，应重点检查应用自身的并发控制。

常见位置包括：

• Web工作进程数量不足。
• 线程池或协程调度器队列增长。
• 数据库连接池耗尽。
• 下游HTTP连接池不足。
• 全局锁、缓存锁或文件锁竞争。
• 垃圾回收暂停。
• 同步调用第三方或内部服务。
• 单个慢接口占满有限的工作线程。
• 重试机制放大了原始请求量。

例如，应用配置了 100 个工作线程，但其中 80 个都在等待数据库连接，20 个在等待外部接口。CPU可能只有 35%，带宽也很低，但新的请求只能进入应用队列。此时增加服务器带宽不会缩短等待时间，增加线程甚至可能进一步增加数据库和上游压力。

应用指标应与请求耗时分解结合：

数据库瓶颈：区分“SQL执行慢”和“拿不到连接”

数据库问题经常被误判为应用问题，因为用户最终看到的是接口响应慢。首先要分清两种等待：

1. 应用已经拿到数据库连接，但SQL执行、锁等待或结果返回很慢。
2. 应用没有拿到数据库连接，请求在连接池中等待。

两者的处理方向不同。可以将以下指标放在同一时间轴：

• 应用数据库连接池总数、活跃数、空闲数。
• 等待获取连接的请求数和等待时间。
• 数据库活跃会话数。
• 锁等待、事务持续时间和阻塞关系。
• 慢查询数量、查询耗时和扫描行数。
• 数据库CPU、内存、缓存命中、磁盘延迟。
• 数据库网络往返时间。
• 应用请求P95、P99和超时率。

如果应用连接池等待从 20 毫秒升到 1.8 秒，但数据库CPU只有 40%，可能是连接池配置过小、连接泄漏或部分连接长时间被事务占用。此时直接扩容数据库计算资源未必有效。

如果连接池等待很小，但SQL执行时间、锁等待和数据库磁盘延迟一起增加，则更接近数据库内部瓶颈。若只有某一类写请求变慢，应进一步看事务提交、索引、锁范围和批量操作，而不是用整站平均耗时做判断。

数据库操作属于高影响变更范围。排查阶段优先使用只读监控、慢查询统计和现有追踪数据，不要直接终止事务、删除数据或修改索引。需要调整SQL、索引、连接池或事务超时时，应先在测试环境验证，并准备配置回滚或版本回退方案。

一组模拟数据如何形成判断

下面用一组模拟监控数据说明“指标A变化—指标B联动—排除替代解释—形成判断”的过程。数据仅用于展示分析方法，不表示实际监控结果。

从这组关系可以得到几个判断：

• RPS没有明显增加，带宽反而略降，因此不像突发流量把线路打满。
• CPU、磁盘延迟和网络重传没有同步恶化，CPU、磁盘和基础网络暂时缺少直接证据。
• 应用排队时间从毫秒级升到秒级，是请求总耗时增加的主要组成部分。
• 数据库连接池等待只有小幅增加，不能排除数据库影响，但当前更像应用工作队列或上游调用占满了执行槽位。
• 需要继续查看工作线程状态、任务队列、外部依赖耗时和接口分布，而不是先购买更高带宽。

如果复查发现应用队列中的请求大多停留在“等待数据库连接”，判断就应转向连接池或数据库；如果这些请求都停留在“等待外部接口返回”，则应检查依赖服务、超时和重试；如果应用队列本身增长但执行时间很短，可能是工作线程数量或调度配置限制。

排除容易误判的替代解释

带宽低，可能是请求量或响应体积本来就低

先检查请求速率、平均响应字节数和响应类型。带宽低而RPS低、响应也小，可能只是业务流量没有达到能产生高吞吐的规模。此时应关注每个请求的等待组成，而不是要求带宽曲线“跑满”。

反过来，若RPS增加、响应体积增加，但带宽仍然不变，同时请求超时和重试上升，可能是服务器已无法及时处理新请求，或者网络存在丢包和发送队列问题。

带宽低，可能是请求卡在发送前

动态页面和API通常先执行逻辑、查询数据，再生成响应。若请求在应用队列、数据库或上游服务处等待，网卡没有数据可发，带宽自然不会升高。可以比较“首字节时间”和“完整响应时间”：

• 首字节时间增加：生成或获取响应之前存在等待。
• 首字节时间基本不变，但完整响应时间增加：发送阶段、客户端读取速度或网络重传值得关注。
• 小响应首字节正常，大响应拖慢：重点查看网络发送、客户端链路和响应压缩。

CPU看起来不高，可能是单核、锁或I/O等待

多核服务器中，一个单线程接口占满单核，整机CPU可能只有 20% 到 30%。应用线程也可能大量等待锁或I/O，导致CPU使用率不高但请求队列不断增长。应查看单核、进程状态、线程等待和运行队列，不能只看总CPU百分比。

磁盘吞吐不高，可能是延迟而不是吞吐

数据库日志、同步写和随机小I/O可能只产生较低吞吐，却有较高延迟。判断磁盘时要看请求大小、IOPS、await、队列和设备利用率的组合。单看MB/s无法排除存储延迟。

平均值正常，可能是长尾请求影响用户

如果P50为 100 毫秒、P95为 400 毫秒、P99为 8 秒，平均值可能仍然看起来不严重。长尾请求会占用连接、线程和数据库资源，并可能触发客户端重试。排查时应保留慢请求样本，按接口和依赖拆分P99。

服务器指标正常，问题可能发生在入口或客户端

需要确认监控位置：是应用服务器、负载均衡、容器、宿主机还是出口网关。还应比较连接建立耗时、TLS耗时、网关排队时间和应用接收时间。如果请求在到达应用前已经等待，应用内部指标自然可能看起来正常。

对客户端侧问题，可以使用同一网络位置的受控探测进行对比，但不要把单次探测结果当成全部用户体验。探测应记录DNS、TCP、TLS、首字节、完整下载、状态码和响应大小，并与服务器端请求日志按时间关联。

建立可执行的排查顺序

第一步：固定异常时间和对照时间

记录用户开始反馈的时间、监控出现异常的时间和恢复时间。选取一段正常时段作为对照，尽量保持相同接口、相同实例和相近请求量。若监控系统存在时区差异，先统一时间口径。

第二步：确认慢的是哪些请求

按接口、状态码、P50/P95/P99、响应大小和上游依赖拆分。不要用整站平均响应时间替代具体接口。若只有下载接口慢，分析方向与登录、查询接口慢不同。

第三步：定位请求耗时增加的阶段

至少比较连接耗时、排队耗时、应用处理耗时、数据库耗时、上游调用耗时和发送耗时。若当前链路没有完整追踪，可先用网关日志、应用日志和数据库慢查询时间戳近似拼接。

第四步：找到与耗时同步增长的队列

观察应用请求队列、工作线程、数据库连接池、数据库锁、磁盘队列、CPU运行队列和网络连接队列。队列的开始增长时间，比某个时刻的绝对值更有判断价值。

第五步：排除资源表面正常造成的误判

检查单核CPU、虚拟机steal、内存压力、磁盘小I/O延迟、网卡丢包重传、容器资源限制和监控采样间隔。对每个候选瓶颈，都要找到至少一个对应的联动指标。

第六步：只做一个主要变量的复测

如果判断为数据库连接池等待，可以在测试环境或受控实例上调整连接池、优化查询或限制并发后复测；如果判断为应用线程队列，则改变工作线程或任务并发后复测；如果判断为网络重传，则从网络路径和出口设备方向验证。

复测时不应只看带宽是否增加，还要同时看：

• P95、P99和超时率是否下降。
• 主要队列是否能够及时清空。
• RPS是否恢复或保持稳定。
• 错误率和重试量是否下降。
• CPU、内存、磁盘和数据库是否出现新的副作用。
• 慢请求是否从一个接口转移到另一个依赖。

如果调整后带宽仍然没有升高，但请求耗时、排队时间和错误率明显改善，说明原问题本来就不是“带宽没有用满”。性能优化的目标是减少有效等待和稳定处理能力，而不是人为制造更多网络流量。

下一次应同时观察的指标组合

为了避免再次被单一带宽指标误导，可以为每个业务入口建立一组固定的关联指标：

带宽曲线仍然有价值，但它应当与请求速率、平均响应大小和请求耗时一起解释。真正有用的判断链条是：先建立同一时间窗口，再看请求耗时在哪一段增加；随后确认哪个队列同步变长；接着用CPU、内存、磁盘、网络、应用和数据库指标排除替代解释；最后通过受控复测确认瓶颈是否消失。