Блог

Главная - Вопросы по программированию - Apscheduler работает с Django, но не работает с gunnicorn

Apscheduler работает с Django, но не работает с gunnicorn

#python #django #gunicorn

#python #django #gunicorn

Вопрос:

Я настраиваю свой планировщик с помощью apscheduler внутри файла с именем Scheduler.py —

 def start_scheduler():
    scheduler = BackgroundScheduler()
    scheduler.add_job(xyz_job, trigger='cron', hour=21, minute=0)
    scheduler.start()

Теперь внутри моего apps.py —

 from. Scheduler import start_scheduler
class AppNameConfig(AppConfig):
    name = 'appname'
    start_scheduler()

Затем из cmd я использую — python manage.py runserver
Мой планировщик работает нормально, и каждый день в 9 вечера планировщик начал работать в фоновом режиме.

PS — Это был API с точками входа и конечной точкой. Я тестировал его с помощью postman. Я получал вывод правильно.

Теперь на моем сервере Linux я делаю то же самое, но вместо использования django я использую gunicorn для предоставления моего API.

Я использую команду — gunicorn -b server_ip:port project.wsgi --workers=2 --daemon

Используя приведенную выше команду gunicorn, мой API все еще работает нормально, и я получаю выходные данные, но мой планировщик не работает.

Кто-нибудь может дать некоторое представление о том, что может быть возможным решением для этого?

Комментарии:

1. В отличие от очень простого встроенного сервера разработки, gunicorn управляет потоками и процессами. Планировщик использует свой собственный поток, и gunicorn может просто завершить этот поток или родительский поток и процесс. Обычно запланированные задания выполняются как команда управления через cron.

2. «xyz_job», упомянутый в сообщении, — это функция, которая заменяет файл pickle, который уже присутствует там, и загружает этот новый файл pickle в переменную. Итак, логично, что если планировщик и gunicorn работают в разных потоках, это не должно препятствовать тому, чего я пытаюсь достичь.

3. Ну, gunicorn не запускается как другой процесс. Он выполняется как родительский процесс всех процессов (и потоков), которые выполняют код (workers). Даже если вы создаете поток и запускаете его в заданное время, с двумя рабочими вы создадите два потока, которые, скорее всего, будут выполнять задачу одновременно, что приведет к состоянию гонки. Вот почему вы никогда не создаете дополнительные потоки в приложениях WSGI.

4. предположим, я даю —worker = 1, теперь gunicorn выполнит код (1 рабочий). Здесь не будет условия гонки, и этот поток будет запускать планировщик в фоновом режиме, а также он будет обслуживать входные данные для API. Но это тоже не работает. P.S. — Я понимаю вашу точку зрения на это условие гонки, потому что ранее я использовал 4 рабочих, и каждый рабочий инициировал это xyz_job (который на самом деле является функцией обучения модели), и были ошибки. Но может быть решением для этого

5. Я не говорил, что он будет работать с одним рабочим, я сказал, что он не будет работать с двумя.