【问题标题】:Statistical Profiling in PythonPython中的统计分析
【发布时间】:2018-02-28 13:22:31
【问题描述】:

我想知道 Python 解释器在我的生产环境中的作用。

前段时间,我编写了一个名为live-trace 的简单工具,它运行一个守护线程,每N 毫秒收集一次堆栈跟踪。

但是解释器本身的信号处理有一个缺点:

尽管就 Python 用户而言,Python 信号处理程序是异步调用的,但它们只能出现在 Python 解释器的“原子”指令之间。这意味着在纯 C 中实现的长时间计算期间到达的信号(例如对大量文本的正则表达式匹配)可能会延迟任意时间。

来源:https://docs.python.org/2/library/signal.html

即使解释器在某些 C 代码中停留了几秒钟,我如何才能绕过上述约束并获得堆栈跟踪?

相关:https://github.com/23andMe/djdt-flamegraph/issues/5

【问题讨论】:

  • @Shark 的“修复间隙”技巧只是一个技巧。想象一下 Python 解释器在方法 foo() 中是 3 秒(在 C 代码中,持有 GIL)。然后在 foo() bar() 被执行之后。如果现在执行计时器,则该技巧确实会在日志中输入 N 次 bar()。诀窍是“猜测”,而不是“知道”。

标签: python profiling usage-statistics


【解决方案1】:

我现在使用py-spyspeedscope。这是一个非常酷的组合。

py-spy 工作在 Windows/Linux/macOS 上,可以自己输出火焰图,并且被主动部署,例如。 2019 年 10 月添加了子流程分析支持。

【讨论】:

    【解决方案2】:

    你试过Pyflame吗?它基于 ptrace,因此它不应该受到 CPython 的信号处理细节的影响。

    【讨论】:

    • 不幸的是 PyFlame 看起来没有维护。我现在使用 py-spy(另一个答案)。
    【解决方案3】:

    也许 Brendan Gregg 的 perf-tool 可以提供帮助

    【讨论】:

    • 我查看了性能工具。似乎它们非常适合一般性能分析。就我而言,我想知道哪些 Python 方法需要很长时间。我想这是我用 perf-tool 看不到的东西。但也许我错了。不过,感谢您提供此链接。
    猜你喜欢
    • 2020-10-09
    • 2011-01-03
    • 2015-10-15
    • 1970-01-01
    • 2017-09-28
    • 2013-06-25
    • 2021-12-03
    • 2018-07-03
    • 2011-02-22
    相关资源
    最近更新 更多