Для postgres Django всегда устанавливает часовой пояс: либо локальный сервер (когда USE_TZ = False), либо UTC (когда USE_TZ = True).Таким образом, django поддерживает «живое переключение» settings.USE_TZ для базы данных postgreSQL DB.
Как вы на самом деле определили, что это узкое место?
Обычно SET TIME ZONE вызывается только при создании соединения с БД.Возможно, вам следует использовать постоянные соединения, используя settings.DATABASES[...]['CONN_MAX_AGE'] = GREATER_THAN_ZERO ( docs ).Таким образом, соединения будут использоваться повторно, и вы будете меньше звонить на SET TIME ZONE.Но если вы используете этот подход, вам также следует внимательно изучить конфигурацию PostgreSQL:
max_connections должно быть больше 1 + максимальный параллелизм сервера wsgi + максимальное количество одновременных заданий cron, которые используют django(если они у вас есть) + максимальный параллелизм рабочих из сельдерея (если они у вас есть) + любые другие потенциальные источники соединений с postgres - , если вы запускаете задание cron для вызова
pg_terminate_backendзатем убедитесь, что CONN_MAX_AGE больше, чем «время ожидания простоя» - , если вы используете postgres на VPS, тогда в некоторых случаях могут быть ограничения на количество открытых сокетов)
- , если выиспользуется что-то вроде pgbouncer , тогда он может уже повторно использовать соединения
- , если вы убиваете сервер, обслуживающий ваш проект django с помощью
sigkill (kill -9), то он может оставить некоторые незакрытые соединенияв БД (но я не уверен)
Я думаю, это также может произойти, если вы используете django.utils.timezone.activate.Но я не уверен в этом ... Это может произойти, если вы вручную вызываете это в своем коде или когда используете промежуточное ПО для этого
Другие возможные объяснения: как вы«профилирование» ваших запросов фактически показывает время всей транзакции