Django 1.11 PostgreSQL-每个会话上都有“ SET TIME ZONE”命令

Question

我们正在一个网站上解决几个性能问题，并且我们注意到命令“ SET TIME ZONE'America / Chicago'”的执行频率很高，以至于在24小时内，在该命令上花费的时间不到1小时（约占数据库CPU总资源的4％）。

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

您对如何消除数据库服务器上的压力有任何想法吗？

Answer 1

对于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服务器的最大并发+使用Django的同时进行的cron作业的最大数量（如果有的话）+芹菜工人的最大并发性（如果有的话）+任何其他与Postgres的潜在连接来源
• 如果您正在执行cron作业以调用pg_terminate_backend，请确保CONN_MAX_AGE大于“空闲超时”
• 如果您在VPS上运行postgres，则在某些情况下可能 限制开放套接字的数量）
• 如果您使用的是pgbouncer之类的内容，则可能已经在重用连接
• 如果您要杀死使用sigkill（kill -9）为django项目提供服务的服务器，则它可能会与数据库建立一些未关闭的连接（但我不确定）

我认为如果您使用django.utils.timezone.activate也可能会发生这种情况。但是我不确定...如果您在代码中手动调用它，或者当您using middleware to do this

时，可能会发生这种情况

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