日誌
沒錯,就是日誌。再多強調在你的應用程式裡保留足量的日誌的重要性也不為過。你應該對重要的內容打日誌。如果你的日誌打的夠好的話,單看日誌你就能發現問題所在。那樣可以節省你大量的時間。
如果一直以來你都在程式碼裡亂用 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提示
🎀
python -mpdb script.py
在輸入-計算-輸出循環(註:REPL,READ-EVAL-PRINT-LOOP的縮寫)環境下,可以有以下操作:
c or continue
q 或 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():
rrrerehed檔案-關聯不喜歡Winpdb?也可以直接包裝PDB在TCP之上運作! 這樣做:try: (一段抛出异常的代码) except: import pdb pdb.pm() # 或者 pdb.post_mortem() 或者(输入 c 开始执行脚本)
import rpdb2 rpdb2.start_embedded_debugger("secretpassword")
很可能有一种更简短的方式来写上面这条命令,
这是一个相当复杂而又强大的工具,但是这里我只提到了一些基本的内容(安装以及基础的命令)
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
…