Básicamente, tengo una lista de 30,000 URL. El script pasa por las URL y las descarga (con un retraso de 3 segundos). Y luego almacena el HTML en una base de datos.¿Por qué mi script python es asesinado al azar?
Y bucles y bucles ...
¿Por qué azar se obtiene "mató."? No toqué nada.
Editar: esto sucede en 3 de mis máquinas Linux. Las máquinas están en una nube de Rackspace con 256 MB de memoria. Nada más se está ejecutando.
Parece que se está quedando sin memoria: puede suceder fácilmente en un programa de larga ejecución si tiene una "fuga" (por ejemplo, debido a la acumulación de referencias circulares). ¿Rackspace ofrece herramientas fácilmente utilizables para realizar un seguimiento de la memoria de un proceso, para que pueda confirmar si este es el caso? De lo contrario, este tipo de cosas no es difícil de controlar con las herramientas normales de Linux desde fuera del proceso. Una vez que ha determinado que la "falta de memoria" es la causa probable de la muerte, las herramientas específicas de Python como pympler pueden ayudarlo a rastrear exactamente de dónde viene el problema (y así determinar cómo evitar esas referencias, ya sea cambiando a referencias débiles u otros enfoques más simples, o elimine las filtraciones).
Creo que se está quedando sin memoria, ¿verdad? Mem: 262364k total, 258264k usado, 4100k libre, 884k buffers Intercambio: 524280k total, 285204k usado, 239076k libre, 14568k en caché – TIMEX
SWAP sigue subiendo y subiendo. – TIMEX
@alex, así que definitivamente parece una "fuga". Además de la aplicación de bolígrafo, que ya he sugerido, prueba guppy - http://guppy-pe.sourceforge.net/ - te pueden ayudar a identificar ** dónde ** está pasando toda esa memoria (mirando tu código, que has publicado como ¡otra pregunta, sin saber sobre todas las bibliotecas de terceros que está utilizando, no es tan útil en ninguna parte!). –
¿Es posible que esté golpeando una excepción no detectada? ¿Estás ejecutando esto desde un shell, o se está ejecutando desde cron o de alguna otra forma automatizada? Si está automatizado, la salida puede no mostrarse en ningún lado.
En casos como este, debe verificar los archivos de registro.
utilizo Debian y Ubuntu, por lo que el archivo de registro principal para mí es: /var/log/syslog
Si utiliza Red Hat, creo que registro es: /var/log/messages
Si ocurre algo que es tan excepcional como el kernel matando su proceso, no será sea un evento de registro que lo explique.
Sospecho que estás siendo golpeado por el Out Of Memory Killer.
¿Está utilizando algún tipo de gestor de colas o gestor de procesos de algún tipo? Obtuve mensajes aparentemente aleatorios cuando el gestor de colas por lotes que estaba usando enviaba SIGUSR2 cuando se acababa el tiempo.
De lo contrario, estoy muy a favor de la opción de falta de memoria.
Para aquellos que vinieron aquí con mysql, he encontrado este respuestas podrán de útiles:
uso SSCursor como suggented por this
conn = MySQLdb.connect(host=DB_HOST, user=DB_USER, db=DB_NAME,
passwd=DB_PASSWORD, charset="utf8",
cursorclass=MySQLdb.cursors.SSCursor)
e iterar sobre el cursor según lo sugerido por this
cursor = conn.cursor()
cursor.execute("select * from very_big_table;")
for row in cur:
# do what you want here
pass
Preste atención a lo que doc dice You MUST retrieve the entire result set and close() the cursor before additional queries can be peformed on the connection., así que si quieres escribir y al mismo tiempo, se debe utilizar otra conexión, o se obtendrá
`_mysql_exceptions.ProgrammingError: (2014, "Commands out of sync; you can't run this command now")`
probablemente sería útil para proporcionar información sobre el entorno en el que se ejecuta un script. Por ejemplo, ¿lo está ejecutando en su propio servidor o en un host compartido? ¿Qué otras cosas están funcionando? Etc ... – Amber
Un error de seguimiento sería útil. De lo contrario, solo estamos adivinando. Supongo que es Zombies del Área 51. –
No hay errores. Solo dice "asesinado". – TIMEX