以下は、デバッグまたは分析を行うときに使用するツールの概要です。より良いツールを知っている場合は、完全な紹介をせずにコメントに残してください。
そうです、ログです。アプリケーション内で適切なログを保持することの重要性は、どれだけ強調してもしすぎることはありません。重要なことは記録する必要があります。ログが十分に良好であれば、ログを見るだけで問題を見つけることができます。これにより、時間を大幅に節約できます。
コード内で print ステートメントをいじっている場合は、今すぐやめてください。代わりにlogging.debugを使用してください。今後も再利用し続けることも、すべて無効にすることもできます。
場合によっては、どのステートメントが実行されたかを確認する方が良い場合があります。 IDE のデバッガを使用してステップ実行することもできますが、どのステートメントを探しているのかを正確に知る必要があります。そうしないと、プロセス全体の進行が非常に遅くなります。
標準ライブラリのトレース モジュールは、実行時に、それに含まれるモジュールで実行されたすべてのステートメントを出力できます。 (プロジェクトレポートを作成するような)
python -mtrace –trace script.py
これにより、大量の出力が生成されます (実行されたすべての行が出力されます。興味のあるモジュールをフィルタリングするために grep を実行するとよいでしょう)。
例:
python -mtrace –trace script.py | egrep '^(mod1.py|mod2.py)'
以下は、誰もが今までに知っておくべき基本的な紹介です:
import pdb pdb.set_trace() # 开启pdb提示
それとも
りーまたは (c と入力してスクリプトの実行を開始します)
try: (一段抛出异常的代码) except: import pdb pdb.pm() # 或者 pdb.post_mortem()
入力-計算-出力ループ(注: REPL、READ-EVAL-PRINT-LOOPの略)環境では、次の操作を実行できます:
c または続行
質問するか辞めてください
lまたはリストで、現在のステップフレームのソースコードを表示します
どこで、呼び出しプロセスを遡ってください
d または下に移動すると、1 フレーム戻ります (注: ロールバックと同等)
u または up、1 フレーム先に進みます
(Enter)、前のコマンドを繰り返します
残りのほぼすべての命令 (他のいくつかのコマンドを除く) は、現在のステップ フレームで Python コードとして解析されます。
それが十分に難しい場合は、スマイリーを試してみてください。変数が表示され、それを使用してプログラムをリモートでトレースできます。
pdb のドロップイン置換:
ipdb (easy_install ipdb) – ipython に似ています (オートコンプリート、表示色などを備えています)
pudb (easy_install pudb) – Curses (グラフィカル インターフェイス インターフェイスに似ています) に基づいており、ソース コードの閲覧に特に適しています
インストール方法:
python -mpdb script.py
次のメソッドを使用して、以前の pdb.set_trace() を置き換えます:
sudo apt-get install winpdb
次に、winpdb、ファイル関連付けを実行します
Winpdb が気に入らない場合は、PDB を直接ラップして TCP 上で実行することもできます。
これを実行します:
rreeREPL 環境が必要なだけですか? IPythonを試してみてはいかがでしょうか?
完全なデバッガーが必要ない場合は、次の方法で IPython を起動するだけで済みます:
import rpdb2 rpdb2.start_embedded_debugger("secretpassword")
あまり活用されていないことによく驚かれます。これらのツールを使用すると、パフォーマンスの問題 (多すぎるシステム コール、メモリ割り当てなど) からデッドロック、ネットワークの問題、ディスクの問題など、幅広い問題を解決できます。
最も便利なのは strace で、最も直接的なものです。 sudo strace -p 12345 または strace -f コマンドを実行するだけです (-f は、フォークから出てくる子プロセスを同時に追跡することを意味します)。 。通常、出力は非常に大きいため、さらに分析するためにファイルにリダイレクトすることができます (ファイル名に &> を追加するだけです)。
次に ltrace があります。これは strace に似ていますが、ライブラリ関数呼び出しを出力する点が異なります。パラメータはほぼ同じです。
ltrace/strace で表示されるハンドル値の意味を指摘するために使用される lsof もあります。例:
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()
使いやすく、多くのことができます。皆さんも htop をインストールしてください。
りー次に、必要なプロセスを見つけて次のように入力します:
import IPython IPython.embed()
適切な継続的なサーバー監視はありませんが、すべての動作が非常に遅いなど、何か奇妙なことに遭遇した場合は、システム リソースは何をしているのでしょうか? 。 。これらの問題を理解したいがどこから始めてもよいわけがない場合は、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 - 继续
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
…
很美,不是吗?
补充:更多有关调试的内容见这里。
原文链接: Ionel Cristian Mărieș 翻译: 伯乐在线 - 高磊
以上が一般的に使用される Python デバッグ ツールの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。