Python 3.15 profiling.sampling 怎样选择 wall 和 cpu 模式

Python 3.15 的 profiling.sampling（Tachyon）同时提供 wall-clock 和 CPU 两种采样模式。遇到“接口变慢”或“计算变重”时，先按问题边界选模式：包含网络、磁盘等待和阻塞时间，用 wall；只想看主动消耗 CPU 的部分，用 cpu。两者都是统计采样，不是精确的函数计时器。

官方地址：https://docs.python.org/3.15/library/profiling.sampling.html

一句话判断：业务总耗时异常先看 wall，确认计算热点再看 cpu；如果问题是精确调用次数或微小差异，改用 tracing 或 timeit。

先看懂 wall 和 cpu 记录的时间边界

wall-clock 记录的是经过了多少现实时间，所以等待 I/O、锁竞争、网络响应或阻塞调用时，调用栈仍可能出现在采样结果里。cpu 模式只关注线程主动执行 CPU 的时间，更适合回答“代码到底把处理器花在哪里”。

这也是为什么两种模式不能简单互换：一个接口的 wall 结果很高，可能是数据库或网络等待；切到 cpu 后占比下降，反而说明瓶颈在外部等待而不是 Python 计算。采样结果由样本次数估算，短函数可能刚好没有被采到。

用最小命令把两种模式分开

先用默认 wall 模式观察完整的经过时间。下面的示例是命令写法，评论说明了参数目的；这里不把示例输出当成真实运行证据。

# wall 模式包含 I/O 等待，适合先找整体耗时来源
python -m profiling.sampling run --mode wall -d 30 --flamegraph -o wall-profile.html app.py

# cpu 模式只聚焦主动计算，适合确认 Python 计算热点
python -m profiling.sampling run --mode cpu -d 30 --pstats app.py

run 适合从脚本启动时开始观察；如果进程已经在运行，则用 attach 连接 PID。生产排障通常先选较短的观察窗口，再根据样本量决定是否延长，而不是一开始就把采样率调到很高。

# 连接已有进程，wall 先看真实请求期间的总耗时
python -m profiling.sampling attach --mode wall -d 30 12345

# 同一个进程再看 cpu，比较主动计算与等待的差异
python -m profiling.sampling attach --mode cpu -d 30 --pstats 12345

如果需要函数级表格，选 pstats；想快速查看调用层次，可选 flamegraph。输出格式改变的是阅读方式，不会把统计采样变成精确计时。

按问题信号选择入口和输出

可以把选择压缩成三类。第一类是接口、任务或服务“总耗时变长”，先使用 wall，因为 I/O 和阻塞本身就是用户等待时间的一部分。第二类是 wall 很高但怀疑 Python 计算过重，再用 cpu 排除等待，把注意力集中到 CPU 热点。第三类是已经知道生产进程的 PID，需要在不改代码的情况下观察，则从 attach 开始。

如果要同时观察线程池中的线程，可以加入 --all-threads；如果要分析异步任务的栈，则根据目标选择 --async-aware。这些参数扩大观察范围，但不改变 wall 与 cpu 的定义。

采样结果怎样复查才不容易误判

第一，观察时间太短时，样本数量不足，结果会有较大波动；可以延长持续时间，或者让短脚本重复运行以获得更多样本。第二，生产分析要用具有代表性的负载，峰值流量和空闲流量都可能把结论带偏。第三，profiling 工具与被连接的目标进程需要使用同一个 Python 小版本，不能用 Python 3.14 的分析器连接 Python 3.15 进程。

最后记住三条边界：wall 是用户视角的耗时线索，cpu 是处理器视角的热点线索，tracing 或 timeit 才适合精确调用和微基准问题。先用 wall 定位大方向，再用 cpu 缩小计算范围，通常比只盯一份百分比更稳妥。

相关问题

wall 模式很高是不是 Python 代码慢？不一定，网络、磁盘、锁和外部服务等待都会抬高 wall；需要用 cpu 做对照。

cpu 模式能代替 timeit 吗？不能。cpu 是运行期间的统计采样，适合找热点；比较几微秒级差异时，应使用 timeit。

为什么两次采样的百分比不完全一样？采样是统计估计，样本数量、负载和线程调度都会造成小幅波动，应关注稳定的热点形状。

总结来说，wall 和 cpu 的选择取决于你要解释的是“用户等了多久”还是“处理器算了多久”。先明确边界，再组合 run 或 attach 与合适的输出格式，最后用持续时间、负载和 Python 小版本复查结论。