Ottenere stacktrace dal processo di pitone bloccato

Question

devo correre un lascito sito zope2 e avere qualche risentimento con esso. Il problema più grande è che, di tanto in tanto, si blocca solo su, in esecuzione a carico della CPU al 100% e non rispondendo alle richieste più. Mentre il problema non è riproducibile su base regolare, una pagina contenente 3 grafici dinamici innesca a volte, così ho il sospetto qualche tipo di condizione di competizione che porta a un ciclo senza fine o un busywait bloccato.

Il problema è che non ho ancora trovato un modo per eseguire il debug di questa cosa. Non c'è niente nei registri di Zope e nulla nei log di sistema. Ho provato i suggerimenti da questa domanda per ottenere uno stacktrace, ma l'unico segnale che ha alcun effetto è SIGKILL.

C'è un'altra possibilità per scoprire dove esattamente il processo è quando si blocca?

Answer 1

Se il processo è bloccato in un modo che nessun altro segnale passa attraverso, si potrebbe prendere in considerazione l'esecuzione da un debugger, invece di cercare di collegare ad esso in fase di esecuzione.

Inoltre, potrebbe essere utile ad altre tattiche di debug, come spegnere alcune parti del codice per scoprire il caso in cui il minimo è ancora riproducibile per vedere quali sono le cause meglio.

Answer 2

È possibile stampare una bella traccia dello stack utilizzando pyrasite .

In primo luogo, è necessario avere installato gdb.

# Redhat, CentOS, etc
$ yum install gdb

# Ubuntu, Debian, etc
$ apt-get update && apt-get install gdb

Quindi, installare pyrasite.

$ pip install pyrasite

Utilizzare ps o qualche altro metodo per trovare l'ID di processo per il processo di pitone bloccato e correre pyrasite-shell con esso.

# Assuming process ID is 12345
$ pyrasite-shell 12345

Si dovrebbe ora vedere un REPL python. Eseguire il seguente nella REPL per vedere tracce di stack per tutti i thread.

import sys, traceback
for thread_id, frame in sys._current_frames().items():
    print 'Stack for thread {}'.format(thread_id)
    traceback.print_stack(frame)
    print ''

Answer 3

Vedere la mia risposta al questa domanda SO , utilizzare Products.signalstack . Si registra lo stesso gestore come la risposta che già trovato, al momento della registrazione del prodotto. Forse funziona meglio per voi.

In caso contrario, probabilmente avete un problema a livello di sistema operativo I / O sulle mani, e la tua unica speranza è collegando gdb al processo. Cerca Stack Overflow per le risposte gdb; v'è una ricchezza di informazioni qui!

Answer 4

Si potrebbe provare a collegare un debugger al processo in esecuzione. Vedi anche questa domanda .

Answer 5

dopo aver eseguito intorno al Internet in tondo per un po 'ho finalmente finito qui: http://podoliaka.org/2016/04/10/debugging-cpython-gdb/ - descrive in dettaglio come tutti i pezzi si incastrano. la citazione soldi per me era 'gdb / usr / bin / python -p $ PID' -. il nome del file eseguibile è necessaria per gdb per trovare i file di debug informazioni corrette