常用的 Python 除錯工具,Python開發必讀

pythontab發表於2013-12-24

以下是我做除錯或分析時用過的工具的一個概覽。如果你知道有更好的工具,請在評論中留言,可以不用很完整的介紹。

日誌

沒錯,就是日誌。再多強調在你的應用裡保留足量的日誌的重要性也不為過。你應當對重要的內容打日誌。如果你的日誌打的足夠好的話,單看日誌你就能發現問題所在。那樣可以節省你大量的時間。

如果一直以來你都在程式碼裡亂用 print 語句,馬上停下來。換用logging.debug。以後你還可以繼續複用,或是全部停用等等。

跟蹤

有時更好的辦法是看執行了哪些語句。你可以使用一些IDE的偵錯程式的單步執行,但你需要明確知道你在找那些語句,否則整個過程會進行地非常緩慢。

標準庫裡面的trace模組,可以列印執行時包含在其中的模組裡所有執行到的語句。(就像製作一份專案報告)

python -mtrace –trace script.py

這會產生大量輸出(執行到的每一行都會被列印出來,你可能想要用grep過濾那些你感興趣的模組).

比如:

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

以下是如今應該人盡皆知的一個基礎介紹:

import pdb
pdb.set_trace() # 開啟pdb提示

或者

try:
(一段丟擲異常的程式碼)
except:
    import pdb
    pdb.pm() # 或者 pdb.post_mortem()
  或者(輸入 c 開始執行指令碼)
  

python -mpdb script.py

在輸入-計算-輸出迴圈(注:REPL,READ-EVAL-PRINT-LOOP的縮寫)環境下,可以有如下操作:

c or continue

q or quit

l or list, 顯示當前步幀的原始碼

w or where,回溯呼叫過程

d or down, 後退一步幀(注:相當於回滾)

u or up, 前進一步幀

(回車), 重複上一條指令

其餘的幾乎全部指令(還有很少的其他一些命令除外),在當前步幀上當作python程式碼進行解析。

如果你覺得挑戰性還不夠的話,可以試下smiley,-它可以給你展示那些變數而且你能使用它來遠端追蹤程式。

更好的偵錯程式

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

  …


相關文章