我经常使用的Python调试工具

时间 2019-12-20

原文原文链接

编者按：题目中的 "我" 是指做者 Ionel Cristian Mărieș, 这是他的我的博客。php

如下是我作调试或分析时用过的工具的一个概览。若是你知道有更好的工具，请在评论中留言，能够不用很完整的介绍。html

日志

没错，就是日志。再多强调在你的应用里保留足量的日志的重要性也不为过。你应当对重要的内容打日志。若是你的日志打的足够好的话，单看日志你就能发现问题所在。那样能够节省你大量的时间。
若是一直以来你都在代码里乱用 print 语句，立刻停下来。换用logging.debug。之后你还能够继续复用，或是所有停用等等。node

跟踪

有时更好的办法是看执行了哪些语句。你可使用一些IDE的调试器的单步执行，但你须要明确知道你在找那些语句，不然整个过程会进行地很是缓慢。
标准库里面的trace模块，能够打印运行时包含在其中的模块里全部执行到的语句。(就像制做一份项目报告)python

python -mtrace –trace script.py

这会产生大量输出（执行到的每一行都会被打印出来，你可能想要用grep过滤那些你感兴趣的模块）.
好比：linux

python -mtrace –trace script.py | egrep '^(mod1.py|mod2.py)'

调试器

如下是现在应该人尽皆知的一个基础介绍：ios

import pdb
pdb.set_trace() # 开启pdb提示

或者git

try:
（一段抛出异常的代码）
except:
    import pdb
    pdb.pm() # 或者 pdb.post_mortem()

或者(输入 c 开始执行脚本)github

python -mpdb script.py

在输入-计算-输出循环(注：REPL，READ-EVAL-PRINT-LOOP的缩写)环境下，能够有以下操做：django

c or continue
q or quit
l or list, 显示当前步帧的源码
w or where,回溯调用过程
d or down, 后退一步帧（注：至关于回滚）
u or up, 前进一步帧
(回车), 重复上一条指令

其他的几乎所有指令（还有不多的其余一些命令除外）,在当前步帧上看成python代码进行解析。
若是你以为挑战性还不够的话，能够试下 smiley，-它能够给你展现那些变量并且你能使用它来远程追踪程序。c#

更好的调试器

pdb的直接替代者：
ipdb(easy_install ipdb) – 相似ipython(有自动完成，显示颜色等)
pudb(easy_install pudb) – 基于curses（相似图形界面接口），特别适合浏览源代码

远程调试器

安装方式:

sudo apt-get install winpdb

用下面的方式取代之前的pdb.set_trace()：

import rpdb2
rpdb2.start_embedded_debugger("secretpassword")

如今运行winpdb,文件-关联
不喜欢Winpdb?也能够直接包装PDB在TCP之上运行！
这样作：

import loggging

class Rdb(pdb.Pdb):
    """
    This will run pdb as a ephemeral telnet service. Once you connect no one
    else can connect. On construction this object will block execution till a
    client has connected.

    Based on https://github.com/tamentis/rpdb I think ...

    To use this::

        Rdb(4444).set_trace()

    Then run: telnet 127.0.0.1 4444
    """
    def __init__(self, port=0):
        self.old_stdout = sys.stdout
        self.old_stdin = sys.stdin
        self.listen_socket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.listen_socket.bind(('0.0.0.0', port))
        if not port:
            logging.critical("PDB remote session open on: %s", self.listen_socket.getsockname())
            print >> sys.__stderr__, "PDB remote session open on:", self.listen_socket.getsockname()
            sys.stderr.flush()
        self.listen_socket.listen(1)
        self.connected_socket, address = self.listen_socket.accept()
        self.handle = self.connected_socket.makefile('rw')
        pdb.Pdb.__init__(self, completekey='tab', stdin=self.handle, stdout=self.handle)
        sys.stdout = sys.stdin = self.handle

    def do_continue(self, arg):
        sys.stdout = self.old_stdout
        sys.stdin = self.old_stdin
        self.handle.close()
        self.connected_socket.close()
        self.listen_socket.close()
        self.set_continue()
        return 1

    do_c = do_cont = do_continue

def set_trace():
    """
    Opens a remote PDB on first available port.
    """
    rdb = Rdb()
    rdb.set_trace()

只想要一个REPL环境？试试IPython如何？
若是你不须要一个完整齐全的调试器，那就只须要用一下的方式启动一个IPython便可：

import IPython
IPython.embed()

标准linux工具

我经常惊讶于它们居然远未被充分利用。你能用这些工具解决很大范围内的问题：从性能问题（太多的系统调用，内存分配等等）到死锁，网络问题，磁盘问题等等。
其中最有用的是最直接的strace，只须要运行 sudo strace -p 12345 或者 strace -f 指令(-f 即同时追踪fork出来的子进程)，这就好了。输出通常会很是大，因此你可能想要把它重定向到一个文件以便做更多的分析（只须要加上 &> 文件名）。
再就是ltrace,有点相似strace，不一样的是，它输出的是库函数调用。参数大致相同。
还有lsof 用来指出你在ltrace/strace中看到的句柄数值的意义。好比：

lsof -p 12345

更好的跟踪

使用简单而能够作不少事情-人人都该装上htop！

sudo apt-get install htop
sudo htop

如今找到那些你想要的进程，再输入：

s - 表明系统调用过程(相似strace)
L - 表明库调用过程(相似ltrace)
l - 表明lsof

监控

没有好的持续的服务器监控，可是若是你曾遇到一些很诡异的状况，诸如为何一切都运行的那么慢，那些系统资源都干什么去了，等这些问题，想弄明白却又无处下手之际，没必要动用iotop、iftop、htop、iostat、vmstat这些工具，就用dstat吧！它能够作以前咱们提过的大部分工做可以作的事情，并且也许能够作的更好！
它会用一种紧凑的，代码高亮的方式（不一样于iostat,vmstat）向你持续展现数据，你还常常能够看到过去的数据（不一样于iftop、iostop、htop）。
只需运行：

dstat --cpu --io --mem --net --load --fs --vm --disk-util --disk-tps --freespace --swap --top-io --top-bio-adv

极可能有一种更简短的方式来写上面这条命令。
这是一个至关复杂而又强大的工具，可是这里我只提到了一些基本的内容（安装以及基础的命令）

sudo apt-get install gdb python-dbg
zcat /usr/share/doc/python2.7/gdbinit.gz > ~/.gdbinit

用python2.7-dbg 运行程序：

sudo gdb -p 12345

如今使用：

bt - 堆栈跟踪（C 级别）
pystack - python 堆栈跟踪,不幸的是你须要有~/.gdbinit 而且使用python-dbg
c - 继续

发生段错误？用faulthandler ！
python 3.3版本之后新增的一个很棒的功能，能够向后移植到python2.x版本。只须要运行下面的语句，你就能够大抵知道什么缘由引发来段错误。

import faulthandler
faulthandler.enable()

内存泄露

嗯，这种状况下有不少的工具可使用，其中有一些专门针对WSGI的程序好比Dozer，可是我最喜欢的固然是objgraph。使用简单方便，让人惊讶！
它没有集成WSGI或者其余，因此你须要本身去发现运行代码的方法，像下面这样：

import objgraph
objs = objgraph.by_type("Request")[:15]
objgraph.show_backrefs(objs, max_depth=20, highlight=lambda v: v in objs,

filename="/tmp/graph.png")
Graph written to /tmp/objgraph-zbdM4z.dot (107 nodes)
Image generated as /tmp/graph.png

你会获得像这样一张图（注意：它很是大)。你也能够获得一张点输出。

内存使用

有时你想少用些内存。更少的内存分配经常可使程序执行的更快，更好，用户但愿内存合适好用)
有许多可用的工具，但在我看来最好用的是 pytracemalloc。与其余工具相比，它开销很是小（不须要依赖于严重影响速度的 sys.settrace）并且输出很是详尽。但安装起来比较痛苦，你须要从新编译python，但有了apt，作起来也很是容易。

只须要运行这些命令而后去吃顿午饭或者干点别的：

apt-get source python2.7
cd python2.7-*
wget? https://github.com/wyplay/pytracemalloc/raw/master/python2.7_track_free_list.patch
patch -p1 < python2.7_track_free_list.patch
debuild -us -uc
cd ..
sudo dpkg -i python2.7-minimal_2.7*.deb python2.7-dev_*.deb

接着安装 pytracemalloc （注意若是你在一个virtualenv虚拟环境下操做，你须要在从新安装python后再次重建 – 只须要运行 virtualenv myenv）

pip install pytracemalloc

如今像下面这样在代码里包装你的应用程序

import tracemalloc, time
tracemalloc.enable()
top = tracemalloc.DisplayTop(
    5000, # log the top 5000 locations
    file=open('/tmp/memory-profile-%s' % time.time(), "w")
)
top.show_lineno = True
try:
    # code that needs to be traced
finally:
    top.display()

输出会像这样：

2013-05-31 18:05:07: Top 5000 allocations per file and line
 #1: .../site-packages/billiard/_connection.py:198: size=1288 KiB, count=70 (+0),
average=18 KiB
 #2: .../site-packages/billiard/_connection.py:199: size=1288 KiB, count=70 (+0),
average=18 KiB
 #3: .../python2.7/importlib/__init__.py:37: size=459 KiB, count=5958 (+0),
average=78 B
 #4: .../site-packages/amqp/transport.py:232: size=217 KiB, count=6960 (+0),
average=32 B
 #5: .../site-packages/amqp/transport.py:231: size=206 KiB, count=8798 (+0),
average=24 B
 #6: .../site-packages/amqp/serialization.py:210: size=199 KiB, count=822 (+0),
average=248 B
 #7: .../lib/python2.7/socket.py:224: size=179 KiB, count=5947 (+0), average=30
B
 #8: .../celery/utils/term.py:89: size=172 KiB, count=1953 (+0), average=90 B
 #9: .../site-packages/kombu/connection.py:281: size=153 KiB, count=2400 (+0),
average=65 B
 #10: .../site-packages/amqp/serialization.py:462: size=147 KiB, count=4704
(+0), average=32 B
…

很美，不是吗？

标准库

标准库有三种分析方法（cProfile和profile，hotshot）以及不可胜数的第三方可视化工具，转化器，以及诸如此类的东西。

工具多了，不靠谱的建议天然少不了。

若是你不知道该用什么，那就用一个可视化的工具吧！

有不少的建议供你选择本身要用的可视化工具，但不管是使用如标准库的Stats模块这种文本形式的仍是像 pycallgraph 或者 gprof2dot 这样的图形化的库，第一反应都是要写代码来生成报表。

可是这个主意很糟糕，你须要不断修改代码来改变或者探索报表的内容。若是你不是在寻找一块特定的代码块，那么一切会变得混乱不堪。你极可能会错过那些真正扼杀你程序性能的事情。

RunSnakeRun

你能够用pip install RunSnakeRun 或者 apt-get install runsnakerun来安装或者从源码安装。

RunSnakeRun 是一个全面的工具，很容易集成 – 你能够和cProfile/profile来配合使用，只须要给profile.run方法指定一个filename的参数便可，好比：

import cProfile
cProfile.run("main()", filename="my.profile")

而后，在终端里运行：

runsnake my.profile

结果看起来就像这样：

这是可接受的，若是你的分析文件不是特别大的话，它会工做的很好。好比：你只有一个占用了太多运行时间的函数。

RunSnakeRun有一个内存调试模式（须要 Meliae ）。遗憾的是我尚未试过。可是若是你想看到内存的使用状况，它看起来确实颇有用。就像[这样](http://www.vrplumber.com/programming/runsnakerun/meliae-sample.png）。

KCachegrind

你能够用apt-get install kcachegrind 来安装或者从源码安装。

不为人知的秘密：有windows版本的KCachegrind二进制包。只须要安装windows版本的KDE，而后在选项“开发者工具”选中它，极可能要取消选择其余项）。

我真的很喜欢这工具！它能够向你展现调用树的图表，可排序的调用表，调用/被调用的地图，源代码，并且你还能选择过滤掉全部的东西。并且它是语言无关的 – 若是你有C/C++背景的话，你极可能据说过这个工具。

我喜欢这个工具的程度超过RunSnakeRun，由于它比后者功能要强大的多：

在调用数的图表上，你能够排序，改变布局/用不少方法来渲染或者导出成点图/png，RunSnakeRun甚至不能显示调用树的图表
你能够看见源码
你能够获得被调用地图
更容易安装（不须要依赖wxPython）

在大项目里面哪些须要关注并非那么显而易见，或者有不少的相关函数时，KCachegrind比RunSnakeRun更值得一用。
可生成KCachegrind 分析文件的工具
我想这是惟一的缺点，你须要用这种特殊的格式导出。可是它也有很好的支持：

pyprof2calltree
django扩展的 runprofileserver
装饰器
kcachegrind 转换器
repoze.profile – 只须要设置cachegrind_filename

我使用的是函数装饰器，无非在你的/tmp目录下多了些导出的分析文件。
附上截图：

还有值得一提的工具？请评论留言！

原文连接： Python debugging tools 、Python profiling tools
转自：伯乐在线：第一篇、伯乐在线：第二篇 - 译者：高磊