我經常使用的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
轉自：伯樂在線：第一篇、伯樂在線：第二篇 - 譯者：高磊

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。