Ik gebruik Celery met RabbitMQ in mijn Django-app (op Elastic Beanstalk) om achtergrondtaken te beheren en ik heb het gedemoniseerd met Supervisor.
Het probleem nu is dat een van de periodetaken die ik heb gedefinieerd mislukt (na een week waarin het goed werkte), de fout die ik heb is:
[01/Apr/2014 23:04:03] [ERROR] [celery.worker.job:272] Task clean-dead-sessions[1bfb5a0a-7914-4623-8b5b-35fc68443d2e] raised unexpected: WorkerLostError('Worker exited prematurely: signal 9 (SIGKILL).',)
Traceback (most recent call last):
File "/opt/python/run/venv/lib/python2.7/site-packages/billiard/pool.py", line 1168, in mark_as_worker_lost
human_status(exitcode)),
WorkerLostError: Worker exited prematurely: signal 9 (SIGKILL).
Alle processen die door de supervisor worden beheerd, werken naar behoren (supervisorctl statuszegt LOPEND).
Ik heb geprobeerd verschillende logs op mijn ec2-instantie te lezen, maar niemand lijkt me te helpen om erachter te komen wat de oorzaak is van de SIGKILL. Wat moet ik doen? Hoe kan ik dit onderzoeken?
Dit zijn mijn instellingen voor bleekselderij:
CELERY_TIMEZONE = 'UTC'
CELERY_TASK_SERIALIZER = 'json'
CELERY_ACCEPT_CONTENT = ['json']
BROKER_URL = os.environ['RABBITMQ_URL']
CELERY_IGNORE_RESULT = True
CELERY_DISABLE_RATE_LIMITS = False
CELERYD_HIJACK_ROOT_LOGGER = False
En dit is mijn supervisord.conf:
[program:celery_worker]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery worker -A com.cygora -l info --pidfile=/opt/python/run/celery_worker.pid
startsecs=10
stopwaitsecs=60
stopasgroup=true
killasgroup=true
autostart=true
autorestart=true
stdout_logfile=/opt/python/log/celery_worker.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_worker.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1
[program:celery_beat]
environment=$env_variables
directory=/opt/python/current/app
command=/opt/python/run/venv/bin/celery beat -A com.cygora -l info --pidfile=/opt/python/run/celery_beat.pid --schedule=/opt/python/run/celery_beat_schedule
startsecs=10
stopwaitsecs=300
stopasgroup=true
killasgroup=true
autostart=false
autorestart=true
stdout_logfile=/opt/python/log/celery_beat.stdout.log
stdout_logfile_maxbytes=5MB
stdout_logfile_backups=10
stderr_logfile=/opt/python/log/celery_beat.stderr.log
stderr_logfile_maxbytes=5MB
stderr_logfile_backups=10
numprocs=1
Bewerk 1
Na het herstarten van selderie beatblijft het probleem bestaan.
Bewerk 2
killasgroup=truegewijzigd in killasgroup=falseen het probleem blijft.
Antwoord 1, autoriteit 100%
De SIGKILL die uw werknemer heeft ontvangen, is geïnitieerd door een ander proces. Je supervisorconfiguratie ziet er goed uit, en de killasgroep zou alleen een door de supervisor geïnitieerde kill beïnvloeden (bijv. de ctl of een plug-in) – en zonder die instelling zou het het signaal toch naar de coördinator hebben gestuurd, niet naar het kind.
Hoogstwaarschijnlijk heeft u een geheugenlek en vermoordt de oomkiller van het besturingssysteem uw proces wegens slecht gedrag.
grep oom /var/log/messages. Als je berichten ziet, is dat jouw probleem.
Als je niets kunt vinden, probeer dan het periodieke proces handmatig in een shell uit te voeren:
MyPeriodicTask().run()
En kijk wat er gebeurt. Ik zou de systeem- en processtatistieken van bovenaf in een andere terminal controleren, als je geen goede instrumenten zoals cactus, ganglia, enz. Voor deze host hebt.
Antwoord 2, autoriteit 3%
Dit soort fouten treedt op wanneer uw asynchrone taak (via selderij), of het script dat u gebruikt, veel gegevens opslaat (in het geheugen). Het veroorzaakt een geheugenlek.
In mijn geval kreeg ik gegevens van een ander systeem en bewaarde ik deze op een variabele, zodat ik alle gegevens (naar het Django-model / Excel-bestand) kan exporteren nadat ik het hele proces heb voltooid.
Hier is de vangst. Mijn script verzamelde 10 miljoen gegevens, toen ik gegevens in de variabele van mijn python verzamelde, was het geheugen aan het leeglopen. Wat de fout opleverde.
Om dit probleem op te lossen, heb ik 10 miljoen gegevens verdeeld in 20 delen (een half miljoen op elk deel). Ik controleerde, wanneer de lengte van de gegevens een half miljoen is, heb ik de gegevens opgeslagen in het mijn eigen favoriete lokale bestand / Django-model. doe dit dan voor het volgende half miljoen enzovoort.
Het is niet nodig om het exacte aantal partities te maken. Het is een idee om een complex probleem op te lossen door op te splitsen in meerdere deelproblemen en de deelproblemen één voor één op te lossen. 😀