Я использую Gunicorn для работы с приложением Django, он работал нормально, пока я не изменил свой тайм-аут с 30 до 900000, я должен был сделать это, потому что у меня был usecase, в котором огромный файл должен был загружаться и обрабатываться ( процесс занимает более 30 м в некоторых случаях), но после этого изменения Gunicorn не реагирует через несколько часов, я думаю, проблема в том, что все рабочие (будучи 30) будут заняты некоторыми запросами после этого количества времени, странно, что это происходит даже если я не запускаю этот длинный запрос вообще, и это происходит с обычным исследованием в django admin. Я хочу знать, есть ли способ отслеживать запросы на пулеметы и видеть, что рабочие заняты тем, что просит, я хочу узнать запросы, которые делают их занятыми. Я пробовал --log-file=- --log-level=debug, но он ничего не говорит о запросах, мне нужны более подробные журналы.
Гуникорн не отвечает
Ответ 1
Из последних документов Gunicorn, на линии cmd/ script вы можете использовать:
--log-file - ("-" means log to stderr)
--log-level debug
или в файле конфигурации, который вы можете использовать:
errorlog = '-'
accesslog = '-'
loglevel = 'debug'
но нет упоминания о формате параметра, указанном в вашем вопросе:
--log-file=-
--log-level=debug
Доступ к журналу по умолчанию для доступа - "Нет" (ref), поэтому снято в темноте, но это может объяснить, почему не принимаются подробная информация о журнале. Ниже приведен пример конфигурационного файла config docs.
Кроме того, вы можете захотеть просмотреть изменение конфигурации ведения журнала в Django.
Ответ 2
В то время как я также ищу хороший ответ, чтобы узнать, сколько рабочих занято, вы неправильно решаете эту проблему. Для выполнения этой задачи вам понадобится рабочий, такой как Celery/RabbitMQ, для асинхронного поднятия тяжелой позиции, в то время как ваш цикл запроса/ответа остается быстрым.
У меня есть script на моем сайте, который может занять 5+ минут, и вот хороший шаблон, который я использую:
- Когда запрос сначала приходит, запускает задачу и просто возвращает HTTP 202 Accepted. Его целью является "Запрос принят для обработки, но обработка не завершена".
- Попросите свой фронт-опрос одинаковую конечную точку (каждые 30 секунд должно быть достаточно). Пока задача не завершена, верните 202
- В конце концов, когда он завершит возврат 200, наряду с любыми данными, которые могут понадобиться интерфейсу.
Для моего сайта мы хотим обновить данные более 10 минут. Я передаю заголовок Accept-Datetime, чтобы указать, сколько лет данных является приемлемым. Если наша локальная кешированная копия старше этого, мы запускаем цикл задачи.