Selery + RabbitMQ + "Wystąpił błąd gniazda"

Question

Używam Celery w Django z RabbitMQ jako brokerem na Heroku. Moja usługa RabbitMQ to CloudAMQP Tough na Heroku. W razie potrzeby mamy do czynienia z częstymi wyciekami pamięci, które próbuję podłączyć, ale generalnie usługa nie ulega pogorszeniu, kiedy to się dzieje.

Gdy strona jest dużym natężeniu ruchu (jak dzisiaj), zaczynam się błędy sporadyczne jak następuje:

Couldn't log in: a socket error occurred 

Zadanie jest całkowicie wyrzucone i nie są zarejestrowane w dowolnym miejscu. Jest to oczywiście problem krytyczny dla biznesu. Moje ustawienia seler są poniżej:

BROKER_URL = os.getenv('CLOUDAMQP_URL', DEFAULT_AMQP) 
CELERY_TASK_SERIALIZER = 'pickle' 
CELERY_RESULT_SERIALIZER = 'json' 
CELERY_ACCEPT_CONTENT = ['pickle', 'json'] 
CELERY_ENABLE_UTC = True 
# CELERY_RESULT_BACKEND = 'djcelery.backends.database:DatabaseBackend'] 
CELERY_STORE_ERRORS_EVEN_IF_IGNORED = True 
CELERY_SEND_TASK_ERROR_EMAILS = True 
CELERY_RESULT_BACKEND = False 
CELERY_IMPORTS = ('business.admin', 'mainsite.views', 'utils.crons', 'mainsite.forms',) 
BROKER_POOL_LIMIT = 5 

# trying to clean up this memory leak 
CELERYD_MAX_TASKS_PER_CHILD = 5 
CELERYD_TASK_TIME_LIMIT = 60*60 

Jestem trochę nowych do selera, więc jestem szczęśliwy, aby zapewnić jak podążać-up cokolwiek dzienniki/etc będą pomocne, ale nie jestem jeszcze pewien, co do zapewnienia w tym momencie. Czy jest coś oczywistego w moich ustawieniach lub środowisku, które wydaje się, że może powodować ten problem w czasie intensywnego traffickowania?

Answer 1

Błąd gniazda może być spowodowany przez zabicie RabbitMQ lub Heroku przez zabójcę systemu Linux pozbawionego pamięci. Gdy serwerowi zabraknie pamięci z powodu nieużywania przydziału pamięci niektórych procesów, jądro Linux próbuje znaleźć przyczynę i zabija związany z nią proces. Używanie zbyt dużej ilości pamięci przez RabbitMQ może spowodować zabicie. można dowiedzieć się, czy Linux OOM zabity szczególny proces używania grep -i kill /var/log/messages*

Użyj poniższych linków, aby uzyskać więcej informacji o konfiguracji & uczących Linux OOM:

How to Configure the Linux Out-of-Memory Killer

Używasz supervisord?

Supervisord to sprytny demon do uruchamiania procesów i monitorowania. Używając tego, możesz upewnić się, że wszystkie działające procesy, takie jak RabbitMQ, zawsze będą działać w górę, nawet jeśli proces zostanie zabity.

Istnieją dwa możliwe przyczyną wycieków pamięci:

1. Jeśli settings.DEBUG to prawda, może to spowodować wycieki pamięci. Upewnij się, że settings.DEBUG, jeśli jest ustawione na False w konfiguracji procesu roboczego.

2. Powinieneś spożytkować zadanie, jeśli planujesz je zachować. Jeśli ich nie zużyjesz, napotkasz problemy z wyciekiem pamięci. Aby rozwiązać ten problem, można zmienić ustawienia za pomocą tych linii:

   # Just ignore the results, in case you're not consuming results. 
   CELERY_IGNORE_RESULT = True 
   CELERY_STORE_ERRORS_EVEN_IF_IGNORED = False