Fondamentalmente, ho una lista di 30.000 URL. Lo script passa attraverso gli URL e li scarica (con un ritardo di 3 secondi in mezzo). Quindi memorizza l'HTML in un database.Perché il mio script python viene ucciso a caso?
Ed loop e loop ...
Perché a caso Get "uccisi".? Non ho toccato nulla.
Modifica: questo accade su 3 delle mie macchine Linux. Le macchine sono su un cloud Rackspace con 256 MB di memoria. Nient'altro è in esecuzione.
Sembra che si stia esaurendo la memoria - potrebbe facilmente accadere su un programma di lunga durata se si dispone di una "perdita" (ad es. A causa dell'accumulo di riferimenti circolari). Rackspace offre strumenti facilmente utilizzabili per tenere traccia della memoria di un processo, quindi è possibile confermare se questo è il caso? Altrimenti, questo tipo di cose non è difficile da monitorare con normali strumenti Linux al di fuori del processo. Una volta stabilito che "la memoria esaurita" è la probabile causa di morte, strumenti specifici di Python come pympler possono aiutarti a tracciare esattamente da dove proviene il problema (e quindi determinare come evitare tali riferimenti - sia cambiando loro a riferimenti deboli, o altri approcci più semplici - o altrimenti rimuovono le perdite).
Penso che sia a corto di memoria, giusto? Mem: 262364k totali, 258264k utilizzati, 4100k gratuiti, 884k buffer Swap: 524280k totali, 285204k utilizzati, 239076k gratuiti, 14568k cache – TIMEX
lo SWAP continua a salire e salire. – TIMEX
@alex, quindi sicuramente sembra una "perdita". Oltre a pympler, che ho già suggerito, prova con guppy - http://guppy-pe.sourceforge.net/ - possono aiutarti a individuare ** dove ** tutta la memoria sta andando (guardando il tuo codice, che hai postato come un'altra domanda, senza conoscere tutte le librerie di terze parti che stai usando, non è assolutamente utile!). –
È possibile che stia colpendo un'eccezione non rilevata? Stai eseguendo questo da una shell, o viene eseguito da cron o in qualche altro modo automatico? Se è automatizzato, l'output potrebbe non essere visualizzato ovunque.
In casi come questo, è necessario controllare i file di registro.
Io uso Debian e Ubuntu, in modo che il file di log principale per me è: /var/log/syslog
Se si utilizza Red Hat, penso che di log è: /var/log/messages
Se succede qualcosa che è eccezionale come il kernel che uccide il tuo processo, ci sarà essere un evento di registro che lo spiega.
Ho il sospetto che tu sia stato colpito dal Out Of Memory Killer.
Si sta utilizzando qualche tipo di gestore code o gestore processi di qualche tipo? Ho ricevuto messaggi apparentemente casuali quando il gestore code che stavo usando inviava SIGUSR2 quando era scaduto il tempo.
Altrimenti preferisco fortemente l'opzione di memoria esaurita.
Per coloro che sono venuti qui con mysql, ho trovato questo risposte possono, di utili:
uso SSCursor come suggented da this
conn = MySQLdb.connect(host=DB_HOST, user=DB_USER, db=DB_NAME,
passwd=DB_PASSWORD, charset="utf8",
cursorclass=MySQLdb.cursors.SSCursor)
e iterare cursore come suggerito da this
cursor = conn.cursor()
cursor.execute("select * from very_big_table;")
for row in cur:
# do what you want here
pass
Fare attenzione a ciò che dice docYou MUST retrieve the entire result set and close() the cursor before additional queries can be peformed on the connection., quindi se si vuole scrivere e allo stesso tempo, è necessario utilizzare un'altra connessione, o avrete
`_mysql_exceptions.ProgrammingError: (2014, "Commands out of sync; you can't run this command now")`
Sarebbe probabilmente utile per fornire informazioni circa l'ambiente in cui lo script è in esecuzione. Ad esempio, lo stai eseguendo sul tuo server o su un host condiviso? Quali altre cose stanno funzionando? Ecc ... – Amber
Un traceback degli errori sarebbe utile. Altrimenti, stiamo solo indovinando. Immagino che sia Zombi dall'Area 51. –
Non ci sono errori. Dice solo "ucciso". – TIMEX