工具链 on Dorkytiger 的小屋

负载生成器：先选模型，再选工具

Mon, 01 Jan 0001 00:00:00 +0000

4.1 负载生成器：先选模型，再选工具

上一节：无　|　下一节：4.2 两类现象，两条路径配套代码：04-toolchain/01-load-generators 前置：0.6 协调遗漏（本节是它的工程落地）

一句话结论

选「开环还是闭环」比选「用哪个工具」重要得多。 同一份代码、同一个服务，两种模型测出的 P99 可能差几百倍——而工具之间的差别通常只有几成。

一、用「跑步机」理解开环与闭环

健身房里有两台跑步机：

跑步机 A（闭环）：跟着你跑

你跑得快，它就快；你跑不动了，它就慢下来。

结果：你永远不会「跑崩」，因为机器会迁就你。跑了 30 分钟，你觉得自己状态不错。

跑步机 B（开环）：按设定速度跑

设定 12 km/h，不管你跟不跟得上。你跟不上就掉下来（或者被拖着走）。

结果：你会真实地暴露极限——什么时候开始吃力、什么时候彻底跟不上。

对应到压测：

	闭环（VU 模型）	开环（到达率模型）
机制	收到响应才发下一个请求	按固定节奏发，不管响应
服务变慢时	自动减少发压	继续按计划发压（请求开始排队）
结果	P99 被系统性低估	暴露真实尾延迟
类比	「你跑不动机器就减速」	「机器不等你」

复习第 0 章 0.6 节：当服务端卡顿 1 秒时，闭环工具在这 1 秒内几乎不发请求，所以这次卡顿只被记录成 1 个慢样本，而不是几百个。服务越糟，报告越好看。

结论：默认用开环。 只有在明确要测「固定并发下的体验」时才用闭环。

二、工具对照表

工具	模型支持	脚本语言	适合场景	注意
k6	开环 + 闭环（多种 executor）	JavaScript	首选：脚本化、CI 友好、阈值断言、多场景	需要 `preAllocatedVUs` 配够
Gatling	开环（injection profile）	Scala DSL	报告漂亮、表达力强	JVM 自身需要预热与调优
wrk2	开环（恒定速率 + HdrHistogram）	Lua（弱）	验证尾延迟、轻量高并发	脚本能力弱，适合单一接口
JMeter	闭环为主	GUI/XML	协议覆盖广、插件生态	资源占用高，GUI 模式不适合正式压测
Vegeta	开环	CLI	简单场景、快速验证	报告与生态弱
Locust	开环/闭环	Python	分布式压测	单机性能一般

选择建议：

两类现象，两条路径

Mon, 01 Jan 0001 00:00:00 +0000

4.2 两类现象，两条路径

上一节：4.1 负载生成器　|　下一节：4.3 async-profiler

一句话结论

剖析工具选错的代价，是得到「没有瓶颈」这个错误结论。 记住一条分叉：CPU 高 → 用 on-CPU 采样；CPU 不高但慢 → 用 wall-clock 采样。 这两条路径的差别，比工具之间的差别重要得多。

一、用厨房理解两种「慢」

一家餐厅出菜慢，有两种完全不同的原因：

现象	厨房状态	类比后端
灶台全开着，厨师忙不过来	CPU 时间被占满	CPU 高：真在算
厨师都闲着，在等食材送到	CPU 空闲，时间花在等待	CPU 不高：在等 IO / 锁 / 下游

关键洞察：这两种情况的排查手段完全不同。

第一种：看「谁在占用灶台」→ on-CPU 采样，找最宽的函数。
第二种：看「厨师在等什么」→ wall-clock 采样，找阻塞点。

如果对第二种情况用第一种工具：你会看到一张几乎空白的火焰图（因为 CPU 没在干活），然后得出「没有瓶颈」的错误结论。

这是新手最常见的分析错误，也是最浪费时间的一种——因为你会反复采集、反复看空图，怀疑是工具坏了。

二、分叉决策表

现象	首选工具	事件类型	你会看到
CPU 接近饱和（> 70%）	async-profiler / JFR	`cpu` / `jdk.ExecutionSample`	火焰图顶部有明确的宽块
CPU 低（< 40%）但延迟高	async-profiler	`wall`	线程大面积停在等待栈上
CPU 的 `sys` 占比高	系统工具 + 火焰图	`cpu`（看内核栈）	系统调用、锁、页错误
GC 停顿与延迟尖刺对齐	GC 日志 / JFR	`jdk.GCPhasePause`	周期性停顿
分配速率高	async-profiler	`alloc`	谁在制造垃圾
吞吐上不去但 CPU 不高	async-profiler	`lock`	锁争用
所有指标都正常但用户说慢	看测量点（第 1 章 1.3）	客户端/网关/tracing	问题可能在网络或上游

三、四种事件的完整分工

事件	采样依据	回答	典型发现
`cpu`	CPU 时间	谁在消耗 CPU？	热点函数、算法问题、序列化开销
`wall`	墙上时间	时间都花在哪（含等待）？	阻塞 IO、锁等待、下游慢
`alloc`	分配的对象	谁在制造 GC 压力？	装箱、字符串拼接、正则编译
`lock`	锁等待时间	谁在抢锁？	锁竞争、临界区过大

记忆方法：

async-profiler：四类火焰图

Mon, 01 Jan 0001 00:00:00 +0000

4.3 async-profiler：四类火焰图

上一节：4.2 两类现象，两条路径　|　下一节：4.4 JFR 与 jcmd 配套代码：04-toolchain/03-async-profiler

一句话结论

async-profiler 是目前 JVM 上最好用的采样剖析器，它最大的价值是四种事件类型（cpu / alloc / lock / wall）——分别回答「谁在忙、谁在造垃圾、谁在抢锁、谁在干等」。只采 CPU 火焰图，等于只用了一个功能的四分之一。

一、用「X 光造影」理解四种事件

给病人做检查，不同的造影剂能看到不同的东西：

造影剂	看到什么	对应事件
看骨骼结构	硬组织的形态	`cpu`：谁在消耗 CPU
看血流	哪里堵住了	`wall`：谁在等待
看代谢活跃区	哪里在异常增生	`alloc`：谁在制造垃圾
看血管交叉点	哪里互相压迫	`lock`：谁在抢锁

关键：不同的病要用不同的造影剂。用看骨骼的 X 光去查血管堵塞，只会得到「没问题」。

二、四类事件的命令与用途

PID=$(jcmd | grep app.jar | awk '{print $1}')

# ① CPU：谁在消耗 CPU（现象：CPU 高）
asprof -d 60 -e cpu -f cpu.html "$PID"

# ② 墙上时间：时间都花在哪（现象：CPU 不高但慢）⭐ 最容易被忽略
asprof -d 60 -e wall -f wall.html "$PID"

# ③ 分配：谁在制造垃圾（现象：GC 频繁、分配速率高）
asprof -d 60 -e alloc -f alloc.html "$PID"

# ④ 锁：谁在抢锁（现象：吞吐上不去、sys CPU 高）
asprof -d 60 -e lock -f lock.html "$PID"

asprof 是 async-profiler 3.x 的启动器名（旧版本叫 profiler.sh，2.x 也支持 asprof 别名）。如果你的版本较老，把 asprof 换成 ./profiler.sh。

JFR 与 jcmd：能常开的剖析与无依赖应急

Mon, 01 Jan 0001 00:00:00 +0000

4.4 JFR 与 jcmd：能常开的剖析与无依赖应急

上一节：4.3 async-profiler　|　下一节：4.5 系统级观测配套代码：04-toolchain/04-jfr-and-jcmd

一句话结论

JFR（JDK Flight Recorder）是唯一适合在生产环境长期开着的剖析工具（开销约 1%），它记录的是「系统发生了什么」的完整事件流。jcmd 则是零依赖的应急手段——什么都不用装，出问题时随手可用。

一、用「24 小时动态心电图」理解 JFR

普通心电图只在医院做几分钟。但有些心脏问题只在特定时刻发作——所以医生给病人戴一个24 小时动态心电图记录仪：

动态心电图	JFR
长期佩戴，开销极小	生产环境常开，约 1% 开销
持续记录，出事时回放	滚动录制，事后 dump
记录多种信号（心率、心律、ST 段）	记录几十类事件（GC、锁、IO、异常…）
不能当场看结果，要事后分析	用 JDK Mission Control 分析

关键价值：性能问题往往偶发且不可复现。JFR 让你能在问题发生后回到现场。

二、JFR 的三种用法

用法一：出问题时临时录一段

PID=$(jcmd | grep app.jar | awk '{print $1}')

# 录制 120 秒，输出到文件
jcmd "$PID" JFR.start name=perf settings=profile duration=120s filename=/tmp/perf.jfr

# 结束后自动停止；也可以手动
jcmd "$PID" JFR.stop name=perf

用法二：滚动录制（推荐用于生产）⭐

# 保持最多 256MB / 1 小时的事件，超出后自动丢弃最旧的
jcmd "$PID" JFR.start name=rolling settings=profile maxsize=256m maxage=1h

# 出问题时立刻 dump（不用等录制结束）
jcmd "$PID" JFR.dump name=rolling filename=/tmp/incident-$(date +%s).jfr

# 不再需要时停止
jcmd "$PID" JFR.stop name=rolling

这是最实用的模式：平时默默记录，出事时 dump 出「过去 1 小时」的事件。

系统级观测：sys、steal 与上下文切换

Mon, 01 Jan 0001 00:00:00 +0000

4.5 系统级观测：sys、steal 与上下文切换

上一节：4.4 JFR 与 jcmd　|　下一节：4.6 应用可观测性配套代码：04-toolchain/05-system-observability

一句话结论

JVM 指标告诉你「应用怎么了」，系统指标告诉你「环境怎么了」。 三个最容易被忽略、信息量最大的系统指标是：sys CPU（内核在忙什么）、steal（被虚拟机邻居抢走多少）、上下文切换次数（锁竞争与线程过多的信号）。

一、用「体检的血检」理解系统观测

去医院看病，医生不会只看你说「哪不舒服」（应用指标），还会让你做血检、尿检（系统指标）——因为身体大环境的问题会表现为各种局部症状。

血检项	对应系统指标	提示
白细胞	`sys` CPU	有"炎症"（系统调用/锁/页错误）
血糖	`steal`	被外部因素影响（虚拟机邻居）
心率	上下文切换	系统在频繁"换人"
肾功能	磁盘 `await`	排毒能力（IO 能力）

关键：应用层的所有指标都建立在系统资源之上。系统层的瓶颈会伪装成应用层的问题。

二、CPU 的五个组成部分（不要只看总数）

# 最常用的三个命令
top -b -n 1 | head -5
pidstat -u -p <pid> 1
mpstat -P ALL 1

top 那一行 %Cpu(s) 的解读：

%Cpu(s): 12.3 us, 34.5 sy,  0.0 ni, 51.2 id,  1.2 wa,  0.0 hi,  0.8 si,  0.0 st
          │        │          │        │        │        │        │        └─ steal（被邻居抢走）
          │        │          │        │        │        │        └─ 软中断
          │        │          │        │        │        └─ 硬中断
          │        │          │        │        └─ IO 等待
          │        │          │        └─ 空闲
          │        │          └─ nice（低优先级）
          │        └─ sys（内核态）
          └─ user（用户态）

指标	高意味着	常见原因
`us`（user）	应用代码在算	正常；如果过高说明 CPU 是瓶颈
`sy`（sys） ⭐	内核在忙	频繁系统调用、锁竞争、页错误、网络栈处理
`wa`（iowait）	等磁盘	磁盘慢或 IO 密集
`si`/`hi`（中断）	网络/设备中断	高流量网络、中断没做多队列
`st`（steal） ⭐	被虚拟机邻居抢走 CPU	云主机超卖；你的优化再多也没用

两个最容易被忽略的指标

sy 高（比如 35%） 是一个强烈信号：

应用可观测性：指标、追踪、日志

Mon, 01 Jan 0001 00:00:00 +0000

4.6 应用可观测性：指标、追踪、日志

上一节：4.5 系统级观测　|　下一节：4.7 数据与中间件观测配套代码：04-toolchain/06-app-observability

一句话结论

应用可观测性由三根柱子支撑：指标（发现问题）、追踪（定位环节）、日志（看清细节）。 三者各有致命陷阱：指标的分位数算法、追踪的采样策略、日志的同步刷盘——任何一个搞错，都会让你在关键时刻拿不到数据。

一、用「生命体征监护仪」理解三根柱子

监护手段	对应	特点
监护仪（心率、血压、血氧）	指标	连续、便宜、能告警；但只有数字，不知道原因
CT/造影（看具体位置）	追踪	能定位到具体环节；但有采样成本
病历（详细记录）	日志	信息最全；但成本高，不能全记

关键：三者互相验证。监护仪报警（指标异常）→ 做 CT（追踪定位）→ 查病历（日志细节）。

二、指标：三个必须避开的陷阱

陷阱一：用平均值或客户端算好的分位数

已在第 1 章 1.2 节讲过：百分位不可平均，必须用直方图。

-- ✅ 正确：先按 le 聚合，再算分位数
histogram_quantile(0.99, sum by (le) (rate(http_server_requests_seconds_bucket[5m])))

-- ❌ 错误：对实例的 P99 求平均
avg(http_server_requests_seconds{quantile="0.99"})

实践检查：如果你的 Prometheus 里出现了 quantile="0.99" 这样的标签，说明你（或某个库）在客户端算了分位数——这在多实例场景下是错的。

陷阱二：桶边界不合适

已在第 1 章 1.2 节讲过。这里补充一个快速检查方法：

# 如果 P99 长期等于某个固定值（比如正好 100ms），说明桶在那一带太稀疏
histogram_quantile(0.99, sum by (le) (rate(http_server_requests_seconds_bucket[5m])))

自检：把桶边界画出来，看 SLO 附近是否加密。

陷阱三：标签基数爆炸 ⭐

// ❌ 灾难：每个用户/订单/URL 一个时间序列
registry.counter("request", "userId", userId)
registry.counter("request", "uri", "/orders/12345")

// ✅ 正确：只用可枚举维度
registry.counter("request", "uri", "/orders/{id}", "status", "200", "method", "GET")

基数的量化影响：

数据与中间件观测：是数据库慢，还是等连接慢？

Mon, 01 Jan 0001 00:00:00 +0000

4.7 数据与中间件观测：是数据库慢，还是等连接慢？

上一节：4.6 应用可观测性　|　下一节：4.8 容器与编排的干扰配套代码：04-toolchain/07-data-and-middleware

一句话结论

「数据库慢」和「等连接慢」是两件完全不同的事，修法也完全相反。 前者要优化 SQL 或加索引，后者要调连接池——搞错了会把问题放大（盲目加连接池 = 把压力转移到数据库）。

一、用「食堂打饭」理解两个不同的瓶颈

食堂里你等了 20 分钟才吃上饭。原因是哪个？

可能原因	类比	修法
打饭窗口只有一个，大家在排队	连接池太小	增加窗口（加连接）——但要小心
厨师做菜很慢，每个人都要等很久	查询慢	让厨师做快点（优化 SQL/加索引）
窗口很多，但厨师只有 2 个	连接够了，但数据库处理能力不足	优化查询，减少并发

关键区别：排队（等窗口）vs 服务慢（厨师慢）。

判断方法：看两个不同的指标——

连接池 pending > 0  →  在排队（等窗口）
连接池 pending = 0 但查询耗时长  →  服务慢（厨师慢）

这两个指标必须同时看，只看一个必然误判。

二、PostgreSQL：四个必看的视图与命令

2.1 `pg_stat_statements`：最贵语句排行榜

-- 前提：在 postgresql.conf 里加 shared_preload_libraries = 'pg_stat_statements'
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- 按总耗时排序（谁最消耗数据库时间）
SELECT
    calls,
    round(total_exec_time::numeric, 1)  AS total_ms,
    round(mean_exec_time::numeric, 2)   AS mean_ms,
    round((100 * total_exec_time / sum(total_exec_time) OVER ())::numeric, 1) AS pct,
    left(query, 70) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

读法（关键）：

容器与编排的干扰：「本地好、上线慢」的头号原因

Mon, 01 Jan 0001 00:00:00 +0000

4.8 容器与编排的干扰：「本地好、上线慢」的头号原因

上一节：4.7 数据与中间件观测　|　下一节：4.9 Lab 4 配套代码：04-toolchain/08-container-interference

一句话结论

容器 CPU limit 会让你的进程被周期性「掐停」——平均 CPU 利用率看起来不高，但延迟会间隔性抖动，P99 明显变差。这是「本地压测很好、上线就慢」的头号原因，而且不看 cgroup 指标几乎不可能发现。

一、用「限速器」理解 CPU 节流

想象你开车，但车上装了一个限速器：

规则：每 100 毫秒的窗口内，最多只能开 10 毫秒的"油门时间"（相当于 CPU limit = 0.1 核）。
你正常行驶时看不出问题（因为大部分时间不需要那么多油门）。

但当你要加速时：

第 1 个 100ms 窗口：你猛踩油门，10ms 用完 → 被强制"断油"剩余 90ms
第 2 个 100ms 窗口：又是一样
...

结果：你的"平均速度"看起来不高（因为大部分时间在滑行），
      但每次踩油门都被强行打断 → 车一顿一顿的。

这就是 CPU 节流：不是「不给你 CPU」，而是「周期性掐断你的 CPU」。

对应到后端

现象	解释
平均 CPU 利用率只有 40%	因为大部分时间被掐停了
P99 间隔性抖动	请求恰好落在被掐停的窗口里
火焰图上看到「什么都没做」的时间	线程被强制暂停
GC 停顿时间变长	GC 线程也被节流
本地无限制 CPU 时完全正常	本地没有 cgroup 配额

二、怎么确认：看 cgroup 的四个值

# cgroup v2（现代 Linux）
cat /sys/fs/cgroup/cpu.max           # 格式：<quota> <period>，例如 "100000 100000" = 1 核
cat /sys/fs/cgroup/cpu.stat          # 关键指标在这里

# cgroup v1（较老）
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us
cat /sys/fs/cgroup/cpu/cpu.cfs_period_us
cat /sys/fs/cgroup/cpu/cpu.stat

cpu.stat 的关键字段：

Lab 4：搭起最小观测回路

Mon, 01 Jan 0001 00:00:00 +0000

4.9 Lab 4：搭起最小观测回路

上一节：4.8 容器与编排的干扰　|　下一节：第 5 章实验设计与方法论配套代码：04-toolchain/09-lab4 预计时长：120 分钟

一、这个 Lab 的目标

把本章的工具串成一条回路：

k6 压测 → 服务 → Prometheus/Grafana → 火焰图
   ↑                                      │
   └──────── 现象 → 假设 → 验证 ←──────────┘

关键不是「每个工具都会用」，而是「它们能互相验证」：指标告诉你哪里有异常，火焰图告诉你是哪行代码，两者对得上，结论才可信。

二、任务清单

#	任务	产出	时长
1	搭观测栈（Prometheus + Grafana）	Docker Compose 一键启动	25 min
2	埋四层指标并验证	`/metrics` 输出含四层	20 min
3	跑通 k6 回路	三条曲线同屏（到达率/QPS/P99）	20 min
4	采四类火焰图并对比	cpu/wall/alloc/lock 各一份	30 min
5	JFR 录制并分析	至少找到一条线索	15 min
6	容器节流检查	确认有无节流	10 min

三、任务 1：观测栈

docker compose -f docker-compose.observability.yml up -d
# Prometheus → http://localhost:9090
# Grafana    → http://localhost:3000 (admin/admin)

验收：Prometheus 的 /targets 页面显示你的应用是 UP。

工具链 on Dorkytiger 的小屋

负载生成器：先选模型，再选工具

4.1 负载生成器：先选模型，再选工具

一句话结论

一、用「跑步机」理解开环与闭环

跑步机 A（闭环）：跟着你跑

跑步机 B（开环）：按设定速度跑

二、工具对照表

两类现象，两条路径

4.2 两类现象，两条路径

一句话结论

一、用厨房理解两种「慢」

二、分叉决策表

三、四种事件的完整分工

async-profiler：四类火焰图

4.3 async-profiler：四类火焰图

一句话结论

一、用「X 光造影」理解四种事件

二、四类事件的命令与用途

JFR 与 jcmd：能常开的剖析与无依赖应急

4.4 JFR 与 jcmd：能常开的剖析与无依赖应急

一句话结论

一、用「24 小时动态心电图」理解 JFR

二、JFR 的三种用法

用法一：出问题时临时录一段

用法二：滚动录制（推荐用于生产）⭐

系统级观测：sys、steal 与上下文切换

4.5 系统级观测：sys、steal 与上下文切换

一句话结论

一、用「体检的血检」理解系统观测

二、CPU 的五个组成部分（不要只看总数）

两个最容易被忽略的指标

应用可观测性：指标、追踪、日志

4.6 应用可观测性：指标、追踪、日志

一句话结论

一、用「生命体征监护仪」理解三根柱子

二、指标：三个必须避开的陷阱

陷阱一：用平均值或客户端算好的分位数

陷阱二：桶边界不合适

陷阱三：标签基数爆炸 ⭐

数据与中间件观测：是数据库慢，还是等连接慢？

4.7 数据与中间件观测：是数据库慢，还是等连接慢？

一句话结论

一、用「食堂打饭」理解两个不同的瓶颈

二、PostgreSQL：四个必看的视图与命令

2.1 pg_stat_statements：最贵语句排行榜

容器与编排的干扰：「本地好、上线慢」的头号原因

4.8 容器与编排的干扰：「本地好、上线慢」的头号原因

一句话结论

一、用「限速器」理解 CPU 节流

对应到后端

二、怎么确认：看 cgroup 的四个值

Lab 4：搭起最小观测回路

4.9 Lab 4：搭起最小观测回路

一、这个 Lab 的目标

二、任务清单

三、任务 1：观测栈

2.1 `pg_stat_statements`：最贵语句排行榜