로그
네, 로그입니다. 애플리케이션에서 적절한 로그를 유지하는 것의 중요성은 아무리 강조해도 지나치지 않습니다. 중요한 내용을 기록해야 합니다. 로그가 충분하다면 로그만 봐도 문제를 찾을 수 있습니다. 그러면 시간이 많이 절약됩니다.
코드에 인쇄 문을 사용했다면 지금 중단하세요. 대신 login.debug를 사용하세요. 나중에 계속해서 재사용하거나 모두 비활성화할 수 있습니다.
추적
때로는 어떤 문이 실행되었는지 확인하는 것이 더 나은 접근 방식입니다. 일부 IDE의 디버거를 사용하여 단계별로 진행할 수 있지만 찾고 있는 명령문이 무엇인지 정확히 알아야 합니다. 그렇지 않으면 전체 프로세스가 매우 느리게 진행됩니다.
표준 라이브러리의 추적 모듈은 런타임 중에 포함된 모듈에서 실행된 모든 명령문을 인쇄할 수 있습니다. (프로젝트 보고서 작성과 유사)
python -mtrace –trace script.py
이렇게 하면 많은 출력이 생성됩니다(실행된 모든 줄이 인쇄됩니다. grep을 사용하여 관심 있는 모듈을 필터링하세요.
예:
python -mtrace –trace script.py | egrep '^(mod1.py|mod2.py)'
Debugger
다음은 A 지금쯤이면 잘 알아야 할 기본 소개:
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 또는 계속
q 또는 종료
l 또는 목록, 현재 단계 프레임의 소스 코드 표시
w 또는 where , 호출 프로세스 추적
d 또는 아래로, 한 프레임 뒤로 이동(참고: 롤백과 동일)
u 또는 위로, 한 프레임 앞으로 이동
(Enter) , 이전 명령 반복
거의 모든 명령(몇 가지 다른 명령 제외)은 현재 단계 프레임에서 Python 코드로 구문 분석됩니다.
충분히 어렵지 않다고 생각되면 스마일리를 사용해 보세요. 변수를 표시하고 프로그램을 원격으로 추적하는 데 사용할 수 있습니다.
더 나은 디버거
pdb를 직접 대체:
ipdb(easy_install ipdb) - ipython과 유사(자동 완성, 색상 표시 등)
pudb(easy_install pudb) – Curs 기반(그래픽 인터페이스 인터페이스와 유사), 특히 소스 코드 탐색에 적합
원격 디버거
설치 방법:
sudo apt-get winpdb 설치
이전 pdb.set_trace()를 다음 방법으로 바꾸세요:
import rpdb2 rpdb2.start_embedded_debugger("secretpassword")
이제 winpdb, file-association을 실행하세요
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는 동시에 포크에서 나오는 하위 프로세스를 추적하는 것을 의미합니다. 시간) 그게 다입니다. 출력은 일반적으로 매우 크므로 추가 분석을 위해 파일로 리디렉션할 수 있습니다(파일 이름에 &>만 추가하면 됩니다).
그리고 strace와 다소 유사한 ltrace가 있습니다. 차이점은 라이브러리 함수 호출을 출력한다는 것입니다. 매개 변수는 거의 동일합니다.
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
…