Как избежать подпотока Django, убитого uWSGI respawn

Question

Я создал веб-сервер Django + uWSGI. Основной поток: когда запрос получен, Django инициирует подпоточный поток с помощью встроенного lib-Threading для написания db асинхронно, а в основном потоке он немедленно ответит клиенту.

Как, uWSGI иногда будет воспитывать рабочий процесс (может быть, когда обработка процесса не обрабатывается?), Что вызвало повреждение фонового подтипа, даже когда оно еще не закончено. Любая подсказка, чтобы избежать uWSGI, чтобы не воспламенить рабочий процесс, у которого есть работающий подпоток?

uWSGI респаун журнала:

DAMN ! worker 4 (pid: 31161) died, killed by signal 9 :(trying respawn ... 

uWSGI ини конфигурации (версия 2.0.12):

[uwsgi] 
# Django's wsgi file 
wsgi-file = /home/fh/dj_uwsgi/dj_site/dj_site/wsgi.py  
master  = true 
processes = 10 
http  = :8001 
threads = 2 
enable-threads = true 
http-timeout = 10  
max-requests = 5000   
chmod-socket = 664 
vacuum  = true  
pidfile = /home/fh/dj_uwsgi/dj_site/uwsgi.pid 
daemonize = /home/fh/log/uwsgi_dj.log 

Джанго (версия 1.8) Код приложения псевдо:

в handlers.py:

import threading 

class SubThreadClass(threading.Thread): 
    daemon = True 

    def run(self): 
     # actions to write db 

def myHandler(): 
    my_sub_thread = SubThreadClass() 
    my_sub_thread.start() 

в views.py :

from handlers import myHandler 

def url_handler(request): 
    myHandler() 
    return HttpResponse() 

Answer 1

Взаимодействие с нитями редко является хорошей идеей в среде, которой вы не управляете.

Вы должны использовать автономную рабочую систему, такую ​​как Celery.

Answer 2

В моем случае эта проблема была вызвана задержкой определенных операций с моей базой данных.

Я использую uWSGI с пирамиде (http://docs.pylonsproject.org/projects/pyramid/en/latest/). Поскольку вы используете Django (Python), очень вероятно, что решение будет работать с вами.

Параметры, приведенные ниже, в файле конфигурации production.ini (раздел [uwsgi]) (http://uwsgi-docs.readthedocs.io/en/latest/Options.html).

Я «решил» эту проблему, используя приведенные ниже правила. Это правило «решает» проблему, так как ее резко уменьшает ее появление. До сих пор я ничего не видел, чтобы вообще этого избежать. У меня также было улучшение производительности (тесты на необходимость, но мы оценили их как хорошее улучшение). Решение в основном увеличивает количество потоков в зависимости от того, сколько подключений позволяет ваша база данных (вы также можете увеличить количество подключений, разрешенных вашей базой данных).

Правила:

определить количество процессов (в процессы параметров в вашем production.ini или эквивалент)

q=n*2 

q - number of processes 
n - number of CPUs/cores 

ДЛя Threads'S количество (резьбу параметр в вашем production.ini или эквивалент)

t=(p*0.8)/q 

t - number of threads 
p - number of connections available in your database 
q - number of processes 

Обратите также внимание на то, что sqlalchemy.pool_size параметр (если вы используете sqlalchemy http://www.sqlalchemy.org/), то должно быть указано то же значение, что и t.

Plus:

Для предотвращения процессов Python доступа к вашей production.ini одновременно после перезапуска вызывая «блокировку» добавить «ленивые-приложения = True» параметр в разделе [uwsgi]. Сделайте это, только если ваша система начинает испытывать проблемы с ней.