高峰期卡顿排查，真正有效的做法不是等卡顿发生时手忙脚乱，而是提前留一份分时段的数据，用时间轴上的指标对比把问题钉死在某个环节。 没有这份数据，你只能靠猜；有了它，服务器、带宽、数据库、代码谁背锅一目了然。
为什么高峰期卡顿总在事后说不清原因
很多运维和站长都有过这种经历：用户反馈下午三点网站打开慢，你赶紧登录服务器看，CPU、内存、带宽全正常，数据库也没有慢查询，等你想深入排查，高峰期已经过去，一切恢复平静，第二天同样的时间点又卡，你守在电脑前,却不知道从哪下手。
问题出在“事后查”这个动作上，卡顿是动态过程，高峰期那几分钟的CPU飙高、连接数暴涨、响应时间拉长，一旦峰值回落，监控图上的曲线会被平滑掉，很多瞬时数据直接丢失，等你收到告警再赶过去，看到的只是“恢复正常”的假象。
行业共识认为，高峰期卡顿排查的核心方法论是“分时段留痕”，在非高峰期、平峰期、高峰期分别采集同一批核心指标，形成横向对比，数据不撒谎，哪一段异常，哪一项指标飙升，谁和谁强相关,对比结果会直接告诉你瓶颈位置。
如何留一份分时段的数据：实操步骤
先定指标：哪些数据必须留
不要什么都记录,聚焦五个关键维度即可：
- 响应时间：页面平均响应、接口P95耗时,P95比平均值更能暴露高峰期的尾部延迟。
- 并发连接数：当前活跃连接数、新建连接速率,TCP连接队列溢出是常见隐蔽瓶颈。
- 资源使用率：CPU使用率、内存使用率、磁盘I/O等待时间，注意是“时间点”而不是“平均值”。
- 数据库指标：活跃会话数、慢查询数量、锁等待时长,高峰期数据库往往是第一嫌疑人。
- 带宽与流量：入口与出口流量、丢包率、TCP重传率,用于区分是带宽跑满还是链路质量差。
按时间点持续采集，形成三组基线
不要只在高潮期看数据，要分时段记录，推荐每天固定三个时间窗口，每个窗口持续5分钟,每秒采集一次：
- 低峰期：比如凌晨4点,拿到系统空载时的基准值。
- 平峰期：比如上午10点,拿到日常业务压力下的常规值。
- 高峰期：针对目标时间段，比如工作日下午3点到4点，或晚上8点到9点,覆盖用户反馈卡顿的高危时段。
连续记录至少一周，一周的数据能覆盖工作日和周末的不同流量形态，也足够让你看出规律，不要只记一天，很多时候卡顿不是每天发生，隔天出现或者每周固定某天出现,只有长周期记录才能抓得住。
选工具：别让采集动作本身影响性能
数据采集不能给服务器添乱,常用的组合如下：
- Node Exporter + Prometheus：采集系统层面的CPU、内存、磁盘、网络指标，轻量,适合主流环境。
- MySQL慢查询日志：数据库慢查询必须开，但注意日志大小,建议只记录执行时间超过1秒的SQL。
- Nginx访问日志：把log_format里加上$request_time和$upstream_response_time,这样每个请求的耗时都有记录。
- Grafana：做可视化面板，设置分时对比视图,把低峰期和高峰期的曲线叠在一起看。
工具本身不需要多复杂，关键是持续运行，你可以写一个crontab脚本，每5分钟把关键指标追加到CSV文件，或者用Prometheus的remote write长期存储，别嫌麻烦，这套留痕机制一旦跑起来，下一次高峰期卡顿,你手里就有第一手证据。
从数据中定位卡顿根源：一张表说清嫌疑对象
当你有了一周的分时数据，把高峰期和非高峰期的指标拉出来对比，基本能锁定方向，下面这张表列出了常见的证据组合和对应结论,你可以直接对照。
| 数据表现 | 可能根源 | 进一步确认方法 |
|---|---|---|
| 带宽使用率达到上限，丢包率升高 | 带宽跑满 | 查看具体是入方向还是出方向，检查是否有大文件下载或CC攻击 |
| CPU使用率飙升，但带宽和数据库正常 | 应用代码效率低 | 抓JVM线程栈或PHP慢日志，看热点函数 |
| 数据库活跃会话数暴涨，慢查询增加 | 数据库瓶颈 | 分析慢查询日志，检查是否有新上线的SQL没走索引 |
| 并发连接数高，但服务器资源空闲 | 连接池或队列配置不足 | 检查Nginx worker_connections和Tomcat的maxThreads |
| 响应时间P95明显高于P50，但资源不高 | 锁竞争或外部接口依赖 | 调用链追踪，看下游服务或API的耗时 |
如何定位高峰期卡顿原因：从响应时间曲线入手
响应时间的拐点是最灵敏的信号，把一天24小时的P95耗时曲线画出来，如果曲线在某个时间点突然陡增，而在其他时间点平滑，说明瓶颈和流量强相关，这时候把你采集的分时数据并排放到一起，观察是哪个指标在同一时间点发生了同步变化，如果CPU曲线和响应时间曲线同步上升，那就是计算资源不够；如果带宽曲线先顶到天花板，而CPU还很低,那优先考虑扩容带宽或压缩资源。
还有一类隐蔽情况：高峰期卡顿不是服务器问题，而是外部依赖变慢，比如你的网站调用了第三方接口，对方在相同时间段也过载，导致你的请求排队，这时候本地所有指标都很正常，唯独接口响应时间波动，所以记录数据时,别忘了给外部API调用加上耗时埋点。
常见高峰期卡顿场景与应对策略
业务高峰遇上缓存穿透
每天中午12点整，大量用户同时访问某几个热门商品，缓存刚好过期，请求全部打到数据库，等数据库扛不住，连锁反应开始，分时数据里的典型表现是：数据库活跃会话数在12点整瞬间拉高,而同一时刻CPU和带宽波动不大。
策略：给热门key设置更长过期时间，或者用互斥锁重建缓存，更简单的办法是直接让热点key永不过期,后台定时更新。
促销活动导致连接数爆掉
活动页面一上线，用户疯狂刷新，服务器TCP连接被占满，新请求进不来，表现为已经打开的页面能加载，但新打开页面白屏，对应数据是并发连接数达到上限,但CPU和内存还有余量。
策略：调大服务器最大文件描述符、Nginx的worker_connections、应用容器的线程池大小，但要注意，连接数调大后，需要同步评估后端数据库的连接数限制,否则只是把压力往下游推。
定时任务和高峰期撞车
每天早上9点开始跑数据报表，正好也是上班族访问网站的高峰，分时数据会显示CPU在9点整出现一个明显的阶梯式抬升，持续十几分钟后回落,间隔几天还会出现更长的尖峰。
策略：把非实时定时任务挪到凌晨执行，或者在任务执行时通过开关限制其对CPU的占用，用分时数据找到撞车窗口,调整调度周期往往立竿见影。
图片或视频资源拖垮带宽
用户访问量并没有暴涨，但高峰期带宽曲线持续高水位，响应时间缓慢，打开具体页面发现，大图、视频没有做压缩和懒加载，分时数据中，出口带宽长时间维持在高速率,而CPU和数据库指标平稳。
策略：启用CDN分发静态资源、图片转WebP格式、视频切片加载，一套操作下来,带宽占用能降一半以上。
网站访问慢是服务器还是带宽：别再凭感觉判断
很多人在排查时喜欢直接看服务器负载，高就怪CPU，低就怪带宽，分时数据能帮你明确区分，你只需要对比两个时间点：低峰期的带宽利用率和高峰期的带宽利用率，如果高峰期的带宽曲线逼近上限，同时响应时间变长，那就是带宽不足，如果带宽还有大量余量，但CPU或数据库已经跑满,那就和带宽无关。
有一个容易忽略的细节：带宽打满不一定是用户访问导致，也可能是服务器往外发送异常数据，比如某个接口返回值过大，或者服务器被植入挖矿程序对外发包，分时数据如果显示出口带宽在凌晨也异常偏高,那就要检查安全方面的问题了。
分时数据的长期价值：预防下一次卡顿
数据留着不只是为了事后解释，更是为了提前预防，当你积累了几个月的高峰期和低峰期数据，你可以做简单的趋势判断：比如每个月的峰值连接数是否逐月上涨，涨幅多大，按照当前增速，预计什么时候会触及硬件上限，这一步能让你在用户感受到卡顿之前,就完成扩容或优化。
分时数据也是复盘的好依据，每次大促或活动结束后，把实际数据和预估对比，哪里超卖、哪里保守，一目了然，下一次做容量规划时，这些数据就是你最可靠的参考,远比拍脑袋准确。
网站高峰期卡顿怎么办？先留数据再谈优化
回到开头的问题，下一次再遇到高峰期卡顿，别急着重启服务器或者骂运营商，先把分时段的数据留下，哪怕当天没有抓到现场，第二天同一时间点你还能继续观察，卡顿大概率是周期性的,一周之内总能抓到两三次。
真正解决问题的前提，是你能用数据还原卡顿现场，分时数据就是你的现场录像，每一秒的指标都在告诉你当时发生了什么，留下来了，你会发现自己从“救火队员”变成了“数据分析师”，排查思路清晰了,优化动作也更有底气。
常见问题解答
高峰期卡顿排查需要记录哪些系统指标？
至少记录响应时间、并发连接数、CPU利用率、内存使用率、磁盘I/O等待、数据库活跃会话数、慢查询数量、带宽使用率和丢包率，再多加一个外部API调用耗时，宁可多记，不可漏记，记录粒度建议5秒一次,峰值数据才有参考价值。
如果当天没抓到高峰期数据怎么办？
先检查监控系统是否覆盖了完整时段，如果确实没有，不要紧，卡顿往往不是单次事件，第二天同一时间窗口提前开启抓包和采样，同时在你怀疑的时间点前后各延长15分钟采集,防止时间偏移造成遗漏。
分时数据怎么对比才能更快找到瓶颈？
把低峰期、平峰期、高峰期的同一指标画在同一张时间序列图上，重点观察三者的差距，差距最大的那项指标，往往就是瓶颈所在，再用响应时间曲线去和相关指标求重叠区域，哪个指标的变化趋势和响应时间曲线最贴合,那个环节就是你需要优化的地方。