Django долго запускает асинхронные задачи с потоками / обработкой
Каков реальный результат здесь?
Ваша программа просочилась в память. В зависимости от вашей ОС может быть восстановлен .
Большинство современных настольных операционных систем делают восстановление утечки памяти при завершении процесса, что делает ее грустным для проигнорируйте проблему, как видно из многих других ответов здесь.)
Но вы полагаетесь на функцию безопасности, на которую не следует полагаться, и ваша программа (или функция) может работать в системе, где это поведение делает в следующий раз «жесткой» утечкой памяти.
Возможно, вы работаете в режиме ядра или в винтажных / встроенных операционных системах, которые не используют защиту памяти как компромисс. (MMU занимают место в памяти, защита памяти требует дополнительных циклов процессора, и не так много, чтобы попросить программиста очистить после себя).
Вы можете использовать и повторно использовать память так, как вы например, убедитесь, что вы удалили все ресурсы до выхода.
3 ответа
os.fork
Вилка клонирует родительский процесс, который в данном случае является вашим стеком Django. Так как вы просто хотите запустить отдельный скрипт на python, это кажется ненужным раздуванием.
подпроцесс
Использование subprocess, как ожидается, будет интерактивным. Другими словами, хотя вы можете использовать это для эффективного запуска процесса, ожидается, что в какой-то момент вы завершите его, когда закончите. Возможно, что Python может очистить вас, если вы оставите один запущенный, но я предполагаю, что это приведет к утечке памяти.
потоки
Потоки - это определенные логические единицы. Они начинаются, когда вызывается их метод run(), и заканчиваются, когда заканчивается выполнение метода run(). Это делает их хорошо подходящими для создания ветви логики, которая будет работать за пределами текущей области. Однако, как вы упомянули, на них распространяется Глобальная блокировка интерпретатора.
мультипроцессинг
Это в основном нити на стероидах. Он имеет преимущества потока, но не подлежит глобальной блокировке интерпретатора и может использовать преимущества многоядерных архитектур. Однако в результате с ними сложнее работать.
Итак, ваш выбор действительно сводится к потокам или многопроцессорности. Если вы можете обойтись с потоком, и это имеет смысл для вашего приложения, переходите с потока. В противном случае используйте многопроцессорность.
Я обнаружил, что с помощью uWSGI Decorators довольно проще, чем с помощью Celery, если вам нужно просто выполнить длинную задачу в фоновом режиме. Думайте, что Celery - лучшее решение для серьезного тяжелого проекта, и это требует дополнительных усилий.
Для начала использования uWSGI Decorators вам просто нужно обновить конфигурацию uWSGI с помощью
<spooler-processes>1</spooler-processes>
<spooler>/here/the/path/to/dir</spooler>
написать код, например:
@spoolraw
def long_task(arguments):
try:
doing something with arguments['myarg'])
except Exception as e:
...something...
return uwsgi.SPOOL_OK
def myView(request)
long_task.spool({'myarg': str(someVar)})
return render_to_response('done.html')
, чем при запуске просмотра в журнале uWSGI появляется:
[spooler] written 208 bytes to file /here/the/path/to/dir/uwsgi_spoolfile_on_hostname_31139_2_0_1359694428_441414
, а когда задача выполнена:
[spooler /here/the/path/to/dir pid: 31138] done with task uwsgi_spoolfile_on_hostname_31139_2_0_1359694428_441414 after 78 seconds
Существуют странные (для меня) ограничения:
- spool can receive as argument only dictionary of strings, look like because it's serialize in file as strings.
- spool should be created on start up so "spooled" code it should be contained in separate file which should be defined in uWSGI config as <import>pyFileWithSpooledCode</import>
На вопрос:
Будет ли порожденный длинный поток блокировать wsgi от выполнения чего-либо еще для другого запроса?!
ответ - нет.
Вы все еще должны быть осторожны при создании фоновых потоков из запроса, хотя в случае, если вы просто создаете их огромное количество и забиваете весь процесс. Вам действительно нужна система организации задач, даже если вы делаете что-то в процессе.
В отношении выполнения форка или exec из веб-процесса, особенно из Apache, это, как правило, не очень хорошая идея, поскольку Apache может навязывать странные условия для среды созданного подпроцесса, которые могут технически мешать его работе.
Использование такой системы, как Celery, по-прежнему, вероятно, лучшее решение.