私がよく使うPythonデバッグツール
8830 ワード
デバッグや分析で使用したツールの概要を以下に示します.もっと良いツールがあることを知っていれば、コメントにメッセージを残して、完璧な紹介をしなくてもいいです.
ログ#ログ#
そう、ログです.あなたのアプリケーションに十分なログを残すことの重要性を強調しても過言ではありません.重要な内容にログを付けるべきです.もしあなたのログが十分に上手であれば、ログを見るだけで問題点を見つけることができます.そうすると、多くの時間を節約できます.
いつもコードでprint文を乱用していたら、すぐに止めてください.loggingとスワップする.debug.後で多重化を続けることもできますし、すべて停止することもできます.
ついせき
より良い方法は、どの文が実行されたかを見ることです.IDEのデバッガの単一ステップを使用して実行できますが、それらの文を探していることを明確に知る必要があります.そうしないと、プロセス全体が非常に遅くなります.標準ライブラリのtraceモジュールで、実行時に含まれるモジュールに実行されたすべての文を印刷できます.(プロジェクトレポートを作成するようなものです)
これにより、大量の出力が発生します(実行された行ごとに印刷され、興味のあるモジュールをgrepでフィルタしたいかもしれません).例:
デバッガ
以下は、今誰もが知っているはずの基礎的な紹介です.
または
または
または(cを入力してスクリプトの実行を開始)
入力-計算-出力サイクル(注:REPL,READ-EVAL-PRINT-LOOPの略)環境では、次のような操作が可能です. c or continue q or quit l or list、現在のステップフレームのソースコード を表示 w or where、遡及呼び出しプロセス d or down、1ステップフレーム後退(注:ロールバックに相当) u or up、前更なるフレーム (リターン)、前の指令 を繰り返す
残りのほとんどのコマンド(他のコマンドを除く)は、現在のステップフレーム上でpythonコードとして解析されます.
挑戦性が足りないと思ったら、smileyを試してみてください.-変数を示すことができ、遠隔追跡プログラムに使用することができます.
より良いデバッガ
pdbの直接代替者:ipdb(easy_install ipdb)-ipython(自動完了、表示色など)pudb(easy_install pudb)-curses(グラフィックインタフェースのような)に基づいて、ソースコードの参照に特に適しています.
リモートデバッガ
インストール方法:
従来のpdbに次のように置換.set_trace():
従来のpdbに次のように置換.set_trace():
winpdbを実行します.ファイル-関連付け
Winpdbは好きじゃないの?PDBを直接包装してTCPの上で運行することもできます!
次のようにします.
REPL環境が欲しいだけ?IPythonはいかがですか?
完全なデバッガが必要ない場合は、IPythonを起動するだけでいいです.
標準linuxツール
私はよくそれらが十分に利用されていないことに驚いた.これらのツールでは、パフォーマンスの問題(システム呼び出しの多さ、メモリ割り当てなど)からデッドロック、ネットワークの問題、ディスクの問題など、幅広い問題を解決できます.その中で最も有用なのは最も直接的なstraceであり、sudo strace-p 12345またはstrace-f命令(-fすなわちforkから出たサブプロセスを同時に追跡する)を実行するだけでよい.出力は一般的に非常に大きいので、より多くの分析のためにファイルにリダイレクトしたい場合があります(&>ファイル名を追加するだけです).
さらにltraceはstraceに似ていますが、ライブラリ関数呼び出しを出力しています.パラメータはほぼ同じです.
またlsofはltrace/straceで見たハンドルの数値の意味を指摘するために使用されます.例:
lsof -p 123345
より良い追跡
使いやすくていろいろなことができます.誰もがhtopを入れなければなりません.
希望するプロセスを見つけて入力します.
モニタリング
継続的なサーバモニタリングはありませんが、なぜすべてが遅いのか、システムリソースが何をしているのかなど、奇妙な状況に遭遇したことがあります...これらの問題を理解したいのに手がつけられないときは、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は、上記のコマンドを書くのにもっと短い方法がある可能性があります.
これはかなり複雑で強力なツールですが、ここでは基本的な内容(インストールとベースのコマンド)について説明します.
python2.7-dbg実行プログラム:
次の操作を行います.
セグメントエラーが発生しましたか?faulthandlerで!
ログ#ログ#
そう、ログです.あなたのアプリケーションに十分なログを残すことの重要性を強調しても過言ではありません.重要な内容にログを付けるべきです.もしあなたのログが十分に上手であれば、ログを見るだけで問題点を見つけることができます.そうすると、多くの時間を節約できます.
いつもコードで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の略)環境では、次のような操作が可能です.
残りのほとんどのコマンド(他のコマンドを除く)は、現在のステップフレーム上で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")
従来のpdbに次のように置換.set_trace():
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 123345
より良い追跡
使いやすくていろいろなことができます.誰もが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