Question

我必须运行一个传统的Zope2网站，并对此表示不满。最大的问题是，它偶尔会锁定，以100％的CPU负载运行而不再响应请求。虽然这个问题不能定期重现，但有时会有一个包含3个动态图形的页面触发它，所以我怀疑某种竞争条件会导致无限循环或陷入忙碌状态。

问题是，我还没有找到调试这个东西的方法。 Zope日志中没有任何内容，系统日志中没有任何内容。我尝试了this question的建议来获取堆栈跟踪，但唯一有效的信号是SIGKILL。

还有另一种可能性，可以找出卡住过程中的确切位置吗？

Answer 1

您可以使用pyrasite打印好的堆栈跟踪。

首先，您需要安装gdb。

# Redhat, CentOS, etc
$ yum install gdb

# Ubuntu, Debian, etc
$ apt-get update && apt-get install gdb

然后，安装pyrasite。

$ pip install pyrasite

使用ps或其他方法查找卡住的python进程的进程ID，并使用它运行pyrasite-shell。

# Assuming process ID is 12345
$ pyrasite-shell 12345

您现在应该看到一个python REPL。在REPL中运行以下命令以查看所有线程的堆栈跟踪。

import sys, traceback
for thread_id, frame in sys._current_frames().items():
    print 'Stack for thread {}'.format(thread_id)
    traceback.print_stack(frame)
    print ''

Answer 2

请参阅我对this SO question的回答，使用Products.signalstack。它在产品注册时注册与您已找到的答案相同的处理程序。也许对你来说效果更好。

如果没有，您可能手上有操作系统级别的I / O问题，而您唯一的希望就是将gdb附加到进程中。搜索堆栈溢出的gdb答案;这里有丰富的信息！

Answer 3

您可以尝试将调试器附加到正在运行的进程。另请参阅this question。

Answer 4

如果进程卡住的方式没有其他信号通过，您可能需要考虑从调试器运行它，而不是尝试在运行时附加到它。

此外，它可能对其他调试策略有用，例如关闭代码的某些部分以找出它仍然可重现的最小情况，以便查看导致它更好的原因。

Answer 5

在圈子里绕圈跑了一段时间后我终于来到这里了：http://podoliaka.org/2016/04/10/debugging-cpython-gdb/ - 详细描述了所有部分是如何组合在一起的。我的钱报价是＆＃39; gdb / usr / bin / python -p $ PID＆＃39; - 需要可执行文件的名称才能使gdb找到正确的调试信息文件。

从陷入困境的python进程中获取stacktrace

5 个答案: