Если на вашем веб-сервере есть запросы, которые выполняются дольше 60 секунд, вы что-то делаете не так. Даже секунда на запрос — это ужасно долго, а 60 — те, что по умолчанию в nginx — просто ужас. Однако, есть ряд случаев, когда это необходимо/допустимо.
Поэтому "--yes-run-as-root", больше предупреждать и отговаривать не буду.
В конфиге uwsgi.ini увеличим время harakiri (до 10 минут):
harakiri = 600
В конфиге nginx увеличим timeoutы:
proxy_connect_timeout 600; proxy_send_timeout 600; proxy_read_timeout 600; send_timeout 600; uwsgi_read_timeout 600;
— в блоке location, который отвечает за uwsgi_pass.
После этого
systemctl restart uwsgi systemctl reload nginx
Ну или как вы делаете перезапуск юнитов/тасков uwsgi, nginx.
Альтернативы увеличению тайм-аутов
Если у вас каждый запрос выполняется более 60 секунд — было бы неплохо посмотреть, где тратится время. Поискать debug-toolbarы под ваш фреймворк, посмотреть explain sql-запросов (если используете sql базу данных).
Если это разовые операции / пересчёт статистики / выгрузка данных, то есть 2 простых способа сделать эти запросы менее «вредными» для работы сервиса.
Отложенное выполнение в очереди, отсылка по почте
Часто менеджеры / маркетологи довольны наличию выгрузок / пересчёту статистики не из веб-интерфейса, а, например, из почты.
Тогда можно оставить в покое веб-интерфейс и сделать всё через воркеры. В этом случае нам потребуется очередь задач. Такие очереди обычно основаны на Redis или RabbitMQ (и прочих AMQP реализациях). В частности, для python можно воспользоваться python-rq. Для django есть его обёртка — django-rq, в которой можно даже смотреть на кол-во задач в очереди и перезапускать упавшие задачи.
Отправлять результаты можно, например, по почте.
Это вариант предоставления информации после запроса. Очередной пример масштабирования по времени.
Выполнение по cron, сохранение на сервере
С другой стороны, может быть ситуация, когда несколько менеджеров будут пользоваться статистикой. Сама же статистика их устраивает за предыдущий день. Тогда будет рационально предгенерировать файлы статистики. Выбираем наименее нагруженное для сервера время, добавляем в cron задачу (программу, которую мы написали) по генерации статических файлов отчётов. Ну и добавляем для них правило в nginx.
Это вариант предоставления информации до запроса (прогрев кеша). Также является примером масштабирования по времени.