Django 1.11 PostgreSQL - 每个会话的“SET TIME ZONE”命令

Question

我们正在解决我们的一个网站上的几个性能问题，我们注意到命令“SET TIME ZONE 'America/Chicago'”被执行得如此频繁，在 24 小时内，不到 1 小时（或大约 4% 的总 DB CPU 资源）用于运行该命令。

请注意，“USE_TZ”设置为 False，因此根据我的理解，所有内容都应以 UTC 格式存储在数据库中，并且仅在必要时在 UI 中转换为本地时区。

您对我们如何消除数据库服务器上的这种压力有什么想法吗？

Answer 1

对于 postgres Django 总是设置时区：服务器的本地 (when USE_TZ = False) 或 UTC (When USE_TZ = True)。这样 django 就支持settings.USE_TZpostgreSQL DB 后端的“实时切换” 。

你是如何确定这是一个瓶颈的？

通常SET TIME ZONE仅在创建与 DB 的连接期间调用。也许您应该通过使用settings.DATABASES[...]['CONN_MAX_AGE'] = GREATER_THAN_ZERO( docs )来使用持久连接。这样，连接将被重用，您将减少对SET TIME ZONE. 但是如果您使用这种方法，您还应该仔细查看您的 PostgreSQL 配置：

• max_connections 应该大于 1+wsgi 服务器的最大并发数 + 使用 django 的并发 cron 作业的最大数量（如果有的话）+ celery worker 的最大并发数（如果有的话）+ 任何其他潜在的 postgres 连接来源
• 如果您正在运行要调用的 cron 作业，请pg_terminate_backend确保它CONN_MAX_AGE大于“空闲超时”
• 如果您在 VPS 上运行 postgres，那么在某些情况下可能会限制打开套接字的数量）
• 如果您使用的是pgbouncer 之类的东西，那么它可能已经在重用连接
• 如果您使用sigkill( kill -9)杀死为您的 django 项目提供服务的服务器，那么它可能会留下一些未关闭的与 DB 的连接（但我不确定）

我认为如果您使用django.utils.timezone.activate. 但我不确定......如果您在代码中手动调用它或使用中间件执行此操作时可能会发生这种情况

其他可能的解释：您“分析”您的请求的方式实际上向您展示了整个交易的时间