一般的に使用される Python デバッグ ツール、Python 開発の必読書

ログ

はい、ログです。アプリケーション内で適切なログを保持することの重要性は、どれだけ強調してもしすぎることはありません。重要なことは記録する必要があります。ログが十分に良好であれば、ログを見るだけで問題を見つけることができます。これにより、時間を大幅に節約できます。

コード内で print ステートメントをランダムに使用している場合は、すぐに中止してください。代わりにlogging.debugを使用してください。今後も再利用し続けることも、すべて無効にすることもできます。

追跡

場合によっては、どのステートメントが実行されたかを確認する方が良い場合があります。 IDE のデバッガを使用してステップ実行することもできますが、どのステートメントを探しているのかを正確に知る必要があります。そうしないと、プロセス全体の進行が非常に遅くなります。

標準ライブラリのトレースモジュールは、実行時に、それに含まれるモジュールで実行されたすべてのステートメントを出力できます。 (プロジェクトレポートを作成するようなもの)

python -mtrace –trace script.py

これにより、大量の出力が生成されます (実行されたすべての行が出力されます。興味のあるモジュールをフィルタリングするには grep を使用するとよいでしょう)。

例:

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

Debugger

以下は、今すぐ誰もが知っておくべき基本的な紹介です:

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 または continue

q または quit

l または list、現在のステップフレームを表示ソースコード

w or where、呼び出しプロセスを再トレース

d or down、1 フレーム戻ります (注: ロールバックと同等)

u or up、1 フレーム進みます

(Enter)、前の命令を繰り返します

残りのほとんどすべての命令 (他のいくつかのコマンドを除く) は、現在のステップ フレームで Python コードとして解析されます。

このチャレンジが十分ではないと感じる場合は、スマイリーを試してみてください。変数を表示したり、プログラムをリモートでトレースするために使用したりできます。

より優れたデバッガー

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 はフォークから出てくる子プロセスを同時に追跡することを意味します) を実行することだけです。それでおしまい。通常、出力は非常に大きいため、詳細な分析のために出力をファイルにリダイレクトすることができます (ファイル名に &> を追加するだけです)。

次に ltrace があります。これは strace に似ていますが、ライブラリ関数呼び出しを出力する点が異なります。パラメータはほぼ同じです。

ltrace/strace で表示されるハンドル値の意味を指摘するために使用される lsof もあります。例:

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

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

　　…