如何查找Too Many Connections异常的来源

Question

我的Django网络应用程序中出现间歇性的“Too Many Connections”异常。在查看了有关“Too many connections”的其他Stackoverflow问题之后，通常看起来编码中的错误（例如，产生一堆线程等）会导致许多睡眠连接。

我已经使用select * from information_schema.processlist order by host;来检查这样的连接，我最多可以看到1或2，但大多数睡眠连接的寿命都不到10秒。

所以，我想知道两件事：

• 是否有（相对简单的）方法来跟踪Django可能导致大量连接的内容？
• 如果真的是在特定时间访问该网站的人太多，那么扩展连接数量的标准方法是什么？

Answer 1

我找到了问题的根源：我们有一个RESTful API，有人正在运行一个周期性脚本，该脚本产生700个左右的线程，以便更快地读取API＃34;

然而，比起原因（非常具体）更重要的是找到它的方法。所以我会提供详细信息，希望如果遇到类似的情况，它会帮助其他人。

有关我的设置的更多详细信息：

• 在云环境中
• 负载均衡器后面的多个Django Web服务器

排除故障的步骤：

1. 如果您越过最大连接数，请使用监控系统发出警报以提醒您。如果没有这个装备，那就是一个轮询MySQL数据库并使用以下select语句来获取信息的脚本： select substring_index(host, ':', 1), count(*) from information_schema.processlist group by substring_index(host, ':', 1);

2. 从轮询/监控检查中查看系统是否有任何模式定期更新。 （例如在我的情况下，我看到它每隔5分钟就会超过最大值。）

3. 检查网络服务器（apache / nginx / etc。）或Django日志，查看在超出时访问哪些网址/视图。 （在我的情况下，这很难确定，因为负载平衡器导致每个服务器上只发生一些违规的URL访问，但基于我最终能够弄清楚的时间模式。）

4. 与造成这种悲伤的人进行友好交谈:)

至于我原始问题的第二部分，因为我处于托管云环境中，操作员控制最大连接数，并且通常根据数据库实例大小对其进行扩展。我试图升级一次但是由于线程很多，我拥有的连接越多，过程就越耗尽。