Python在Ubuntu上如何进行性能分析

Python在Ubuntu上的性能分析实战指南

分析Python性能问题时，首先得搞清楚问题到底出在哪一层：是CPU吃紧，还是内存撑不住？是I/O堵了，还是并发卡了？方向不对，工具再好也是白搭。所以，我们按“系统层→应用层→服务层”这个顺序一层层向下挖，算是最稳妥的路径。

系统层这边，工具选择倒是不少。想实时看看进程表现，top或htop就够了；要分析CPU和I/O的互动，vmstat 1和iostat -c -d 4（需要装sysstat）能给你一个清晰的快照；如果喜欢一个工具搞定一切，dstat和glances也值得一试。至于趋势分析，sar -u 1 5能够提供历史数据做对比。

到了应用层，才真正进入Python主战场。cProfile用来定位函数级别的CPU热点，配合snakeviz可视化，一眼就能看出哪些函数是罪魁祸首。line_profiler则更进一步，能告诉你究竟是哪一行代码在拖慢速度。内存方面，memory_profiler是寻找内存泄漏和不合理增长的好帮手。更妙的是py-spy，它能在不侵入进程的情况下采样，生成火焰图来观察调用栈分布，对运行中的服务尤其友好。

服务层则主要是看吞吐和并发。对HTTP服务来说，ab快速做基准测试，Locust模拟真实用户行为压测，两者结合就能验证优化到底有没有效果。

接下去是一套完整的快速上手流程，按照步骤走，基本不会跑偏。

快速上手流程

第一步：系统资源体检

先用top或htop瞄一眼整体状况，然后vmstat 1看CPU和I/O组合，iostat -c -d 4（记得装sysstat）专门盯着磁盘忙不忙。如果嫌一个一个看太麻烦，直接用dstat或glances来个全局总览。历史趋势方面的数据，sar -u 1 5就能搞定。

第二步：应用热点定位

先用py-spy top --pid 或py-spy record -o profile.svg --pid 做一个非侵入的采样，看看哪个线程在狂吃CPU。然后运行python -m cProfile -o profile.prof your_script.py，生成函数级热点报告，再用snakeviz打开可视化界面，热点函数一目了然。

第三步：逐行与内存细化

针对上一步锁定的热点函数，加上@profile装饰器，运行python -m line_profiler your_script.py.lprof，就能看到每一行的执行时间。如果怀疑内存问题，同样的方法，用python -m memory_profiler your_script.py找出每一行内存变化的细节。

第四步：微基准

如果想测试一小段代码的性能，timeit工具是最佳选择。用python -m timeit -s "from your_module import test" "test()"就能获得一个稳定的执行时间，帮助你快速评估不同实现方案的优劣。

第五步：服务压测

服务跑起来以后，ab -n 1000 -c 100 http://localhost:8000/可以快速看你被压垮了没。但想更真实地模拟用户行为，locust -f locustfile.py配合浏览器打开http://localhost:8089配置并发数，压得才够有说服力。

常用工具与命令速查表

实战示例：定位并优化一个CPU热点

假设你有这样一个脚本，热点很明显在slow_func上：

# profile_demo.py
def slow_func(n):
    s = 0
    for i in range(n):
        s += i * i
    return s

def main():
    total = 0
    for _ in range(100):
        total += slow_func(10_000)
    print(total)

if __name__ == "__main__":
    main()

第一步：函数级热点

运行python -m cProfile -o demo.prof profile_demo.py，然后用python -m snakeviz demo.prof打开浏览器查看，毫无疑问，slow_func占据了绝大部分执行时间。

第二步：逐行热点

给slow_func加上@profile装饰器，运行python -m line_profiler profile_demo.py.lprof，可以精确看到循环内的每一行代码耗时。换句话说，问题就是那个for循环。

第三步：非侵入采样火焰图

脚本运行时，拿到它的PID（比如12345）。执行py-spy record -o profile.svg --pid 12345，然后在浏览器里打开生成的profile.svg。火焰图上，越宽的柱子表明耗时越多，一眼就能确认热点在谁身上。

第四步：优化验证

优化思路很简单：用数学公式代替循环。把slow_func改成：

def slow_func(n):
    return (n - 1) * n * (2 * n - 1) // 6

再跑一遍cProfile或py-spy对比优化前后，你会看到总耗时明显下降，这才是优化的底气。

常见问题与建议

有几个常见的坑值得提一下。采样器和调试器不要混用：用py-spy的时候别同时挂gdb/pdb，否则进程会挂起，数据也失真了。模拟尽量贴近生产环境：调试日志关掉，数据量保持一致，结果才具备参考价值。区分CPU与I/O瓶颈：如果iostat显示磁盘特别忙或vmstat显示上下文切换太多，优先排查I/O和锁竞争，而不是盲目优化代码逻辑。服务压测要测稳态：别只跑几秒就下结论，应该先预热，然后持续压测5到10分钟，关键看p95/p99延迟和错误率，平均值会掩盖很多问题。多线程与多进程的取舍：CPU密集型任务，优先考虑多进程或PyPy/Numba；I/O密集型的话，asyncio配合线程池或连接池才是正解。