【问题标题】:- Large # of MySQL lost connections and failures to connect- 大量的 MySQL 丢失连接和连接失败
【发布时间】:2013-07-01 23:58:04
【问题描述】:

我在我们的一个网站的日志文件中看到了很多这样的错误:

  • “读取授权数据包”时与 MySQL 服务器的连接丢失
  • “读取初始通信数据包”时与 MySQL 服务器的连接丢失
  • 无法通过套接字连接到本地 MySQL 服务器
  • 用户已经有超过 'max_user_connections' 活动

事实上,日志文件已经填满了这些错误。有问题的网站每天只有 500 名访问者,尽管当某些后台 PHP 脚本运行时,它确实在一天内处理了 100,000 多个查询。

连接总是在脚本完成后显式关闭。没有持久连接。

几乎每个不时运行的脚本都会发生这种情况,并且 MySQL 服务器每天崩溃几次。

这可能是某种配置问题吗?

  • MySQL 5.1.69-cll
  • PHP 5.2.17
  • Apache 2.2.24

【问题讨论】:

  • 添加更具体的数据。
  • 您是否有长时间运行的查询导致连接堆积(从而达到最大连接限制)?不幸的是,这可能是一个无法通过 SO 进行故障排除的问题。我的建议是查看 MySQL 慢查询日志(如果您启用了它 - 如果您没有启用它,请启用它)以查看您可能在那里显示的查询类型。此外,您可能希望使用show processlist 监控数据库状态,以查看是否有时间长时间运行的查询导致其他查询必须等待表锁定。
  • @MikeBrant 有一些运行时间很长,但它们每天最多运行 2-3 次,通常最多持续 30 秒。最大用户连接数设置为 250,我从未见过一次超过 25 个连接到服务器。
  • 不知情的猜测:出于某种原因,有问题的脚本会为它们所做的每个查询(或一些类似的高度迭代案例)创建一个到 MySQL 的新连接。之前的连接并没有关闭,而是一直处于空闲状态,直到脚本完成,此时所有连接都被 PHP 的退出例程关闭。
  • 很有可能,但不知道会发生什么。我只知道每个脚本有 1 个 mysql_connect() 实例。

标签: php mysql apache


【解决方案1】:

我以前曾在无状态的三层架构中看到过这种行为,每层都有负载平衡。在这种情况下,其中一个应用层服务器具有数据库凭据的旧密码,但所有其他应用层服务器都具有正确的新密码。可能不是您的问题,但您的描述非常相似。

【讨论】:

    猜你喜欢
    • 2016-08-04
    • 2012-03-27
    • 2019-03-01
    • 1970-01-01
    • 2019-12-31
    • 2017-12-06
    • 1970-01-01
    • 2018-12-13
    • 2016-03-19
    相关资源
    最近更新 更多