Django应用程序中的后台定期任务让DB不知所措

我们有一个Django应用程序，它必须定期使用第三方API为一组用户获取大量数据。这些任务执行得很好，完全达到了目的。但一段时间后，我们开始从postgres收到太多的连接错误

致命：抱歉，已经有太多客户端了

信息 项目是固定的，所有组件都运行在单独的容器中，包括应用程序和数据库（）。定期任务由periodiq执行和安排。 我们还使用redis作为系统代理

我曾尝试过各种变通方法来阻止它，但没有一种方法有效，包括在SO中提出的各种解决方案

尝试1 我在执行每个任务之前和之后使用了

connection.closes（）

，以确保工作人员没有打开任何重影连接

尝试2 添加一个任务限制器，以便在给定时间限制活动连接的数量，并防止数据库被淹没。虽然此解决方案甚至不服务于我们实现的实际范围，因为它明显降低了任务执行的性能，但它并没有帮助解决问题

尝试3 增加Postgres的池限制。按照建议，我添加了一个自定义配置文件以增加可用池。这产生了效果，但只是推迟了错误的显示，并没有像预期的那样避免这种情况的发生。我甚至达到了非常高的10K连接限制（从默认的10个）。我在这里发布配置文件，以防它有所帮助

注意该应用程序在一台具有24核和128GB内存的服务器上运行，在执行任务时，它不会占用超过1%的资源

max_connections = 100000
shared_buffers = 64GB

尝试4 我已经插入到项目中，以便将请求排入db队列。这一个避免了数据库被淹没，但这不是一个实际的解决方案，因为它导致数据库连接永远等待，这也使得数据库可用

尝试5 使用

CONN\u MAX\u AGE=0

防止Django创建持久连接。这也没有效果

尝试6 尝试使任务在计算机上运行。这似乎也没什么帮助

---

我认为，任务在dramatiq worker上以并行线程的方式执行会导致连接保持打开状态，但处于空闲状态。我试图手动关闭来自戏剧和periodiq容器的连接，但这在修复连接池问题方面几乎没有效果

我试过了我在SO上找到的所有变体

# Command 1
connection.close

# Command 2
for c in connections.all():
    c.close()

# Command 3
close_old_connections()