在过去的几周里，我们已经多次达到了1500的mysql连接限制。突然间，Threads_connected刚刚爆炸（仅在几分钟内就会爆炸300 - > 1500）。
我们的前端服务器（3x）使用持久连接来连接数据库服务器（1x）。即使在线程耗尽时，我们的数据库服务器也似乎做得很好（CPU，内存，IO）。
我正在考虑在我们的应用程序（cakePHP）中从持久连接切换到非持久连接。我能期待什么？
这样做是个好主意，还是我应该更多地增加连接限制？
答案 0 :(得分：0)
由于数据库和应用程序服务器位于不同的计算机上，因此至少可以预期由于打开新连接而导致脚本执行延迟。如果两个服务器都在局域网中，那可能是微不足道的。
显然，额外的任务会产生额外的负担，但我敢说这也几乎不会引起注意。与处理查询或脚本执行的任何其他操作相比，打开连接是一个很小的开销。
现在，对于手头的真正问题。正如mikey所说，您可能想要调查问题的原因。如果使用持久连接，则每个Web服务器线程都可以打开并维护一个数据库连接。如果负载只有很小的峰值，这会大大增加连接量。对于持久性和非持久性连接，问题实际上是相同的，除了非持久性连接之后就会消失，并且不会通过不必要地占用内存来减缓未来的操作。
通常，如果要保证每个数据库连接都成功，则必须确保mySQL Server可以处理与Web服务器接受并发连接一样多的连接。但是，在实际设置中，您的Web服务器可能会为与数据库无关的连接提供服务。 （图片，CSS，JavaScript等）。考虑到这一点，您可以提供比数据库连接更多的Web服务线程，但有一个问题，也可能是您的问题的根源：
如果有人以不同于正常使用模式的方式访问您网站上的大量网页，则上述规则不适用。例如，如果搜索引擎抓取您的网站。它们不像浏览器那样处理内容。他们可以专注于您的PHP页面，打破每个客户端将加载混合数据的假设。如果这是一个问题，则取决于您与常规用户数量相比的页数。如果您的数据库服务器在高负载下速度变慢，延迟其他连接的处理，则此效果也可以累积。
因此，有意义的是不使用持久连接并管理数据库服务器上的内存，以便可以支持接近最大连接，但代价是文件缓存和缓冲区，但返回到一旦尖峰结束，正常（更快）的操作。
P.S。：确保您了解在使用所有连接时您的数据库将真正使用多少内存。 http://www.mysqlperformanceblog.com/2006/05/17/mysql-server-memory-usage/。不要在确保拥有所需内存的情况下增加允许的连接数量。最好是连接尝试失败，而不是数据库服务器暂停，因为它的缓冲区正在被换出。
答案 1 :(得分：0)
你应该在PHP中关闭持久连接，它们不能像你期望的那样工作。实际上，与不使用它们相比，你实际上拥有更多开放，空闲的连接。手册中的警告实际上警告连接用尽。 http://php.net/manual/en/function.mysql-pconnect.php
您还应该阅读： http://www.php.net/manual/en/features.persistent-connections.php
底线是持久连接不会按照应有的方式重用。您看到的峰值可能是机器人爬行您的站点，并为每个页面加载建立新的连接。
您可以预期用完的连接问题就会消失。如果Web服务器和数据库服务器之间的网络连接快速可靠，则始终建立新连接的额外时间和负载将不会明显。在这方面，MySQL实际上非常有效。
答案 2 :(得分：0)