如果仅仅是因为高计算量卡住 CPU ， 正常处理请求的逻辑将很难被调度到 。 这样势必会造成处理请求的延迟增大 ， 甚至有超时返回的风险 。
使用 spp 的cost_stat_tool工具利用 spp 自带的统计工具印证这一风险点 ， 查看 worker 处理前端请求时延统计信息 ， 执行命令./cost_stat_tool -r 1：
文章插图
上边的例子中 ， 统计发生配置更新前后的 5 秒钟内 ， worker 处理的 231 个请求中 ， 有 3 个请求的处理时间超过 500ms ， 远高于普通请求 。
使用tcpdump抓包确认因该服务没有打开详细的日志 ， 想要进一步验证超过 500ms 的这些请求也是正常处理的请求 ， 而非异常请求 ， 可以通过抓包来分析 。
tcpdump -i any tcp port 20391 -Xs0 -c 5000 -w service_spp.pcap通过 wireshark 打开 ， 需要过滤出返回时间 - 请求时间 > 500ms的相关请求 。 翻译成 wireshark 过滤器的表达式则是：
tcp.time_delta > 0.5--tt-darkmode-color: #8F9BAB;">过滤出一条符合条件的请求：
文章插图
在该条记录上右键 -> Follow -> TCP Stream ， 可以查看该请求前后的 IP 包：
文章插图
上边 4 个包分别是：


1. +0ms 客户端发送请求至服务端
2. +38ms 服务端回复 ACK ， 无数据
3. +661ms 服务端发送返回至客户端
4. +662ms 客户端回复 ACK

详细看了包中的内容为一条普通请求 ， 逻辑简单 ， 应该在 20ms 内返回 。 而此时的该进程使用 CPU 也确实为高负载的情况：
文章插图
上述统计相互印证：

• CPU 高时 ， 正常的网络请求也会被阻塞住（回复 ACK 需要 38ms ， 低于 40ms ， 与TCP 延迟确认无关）
• 平时只需要 20ms 能返回的请求 ， 耗时了 660ms

CPU 突然飚高有风险 ， 需要认真对待 。

• 上一页
• 1
• 2
• 下一页

• 黑莓(BB.US)盘前涨逾32%，将与亚马逊开发智能汽车数据平台|美股异动 | US
• 世代|Z星球——腾讯布局Z世代教育社交的新尝试
• 开发自|不妥协不追随 Member’s Mark升级背后的“山姆哲学”
• 王储|壹周游闻第20期：直播打赏实行实名制；沙特王储收购SNK
• 环境|环境标识认知转盘游戏
• 展开|天地在线联合腾讯广告在京展开“附近推” 构建黄金5公里营销体系
• 确认|三星确认正在开发“轻薄轻巧”的可折叠手机
• realme X|手机打游戏太卡？行家：那是你还没换这几款
• 推广|Josh Elman加盟苹果 负责开发者关系与软件推广工作
• Play|Google Play公布2020年度最佳应用和游戏排行榜