今天早上我注意到我们的MySQL服务器负载高涨.Max应为8,但一度达到100.当我检查进程列表时,我发现大量更新查询(简单的,递增"hitcounter")处于query end状态.我们无法杀死他们(嗯,我们可以,但他们killed无限期地留在该州),我们的地点停了下来.
我们在重新启动服务时遇到了很多问题,不得不强行杀死某些进程.当我们这样做时,我们能够让MySQLd重新启动,但进程立即开始再次建立.据我们所知,目前还没有改变任何配置.
因此,我们innodb_flush_log_at_trx_commit从2 更改为1(请注意,我们需要ACID合规性),希望这可以解决问题,并将PHP/PDO中的连接设置为持久性.这似乎工作了一个小时左右,然后连接又开始耗尽.
幸运的是,我在几个月前设置了一个奴隶服务器并且能够推广它并且它现在正在消耗松弛,但我需要理解为什么会发生这种情况以及如何阻止它,因为从服务器的功能明显不足与主人相比,所以我需要尽快换回来.
有没有人有任何想法？可能是需要清理的东西吗？我不知道是什么,也许是二进制日志还是什么？有什么想法吗？非常重要的是我们可以尽快将这台服务器作为主服务器,但坦率地说我不知道在哪里看,我到目前为止所尝试的一切只会导致临时修复.
救命!:)
Eng*_*r81 28
我会在这里回答我自己的问题.我用简单的df命令检查了分区大小,在那里我可以看到/ var是100%已满.我找到了一个有人留下的存档,大小为10GB.删除,启动MySQL,运行PURGE LOGS BEFORE '2012-10-01 00:00:00'查询以清除空间负载并将/ var/lib/mysql目录大小从346GB减少到169GB.改回主人,一切都恢复正常.
从这里我了解到我们的日志文件变得非常大,非常快.因此,我将建立一个维护例程,不仅要保持日志文件,还要在我们接近完整分区时提醒我.
我希望将来有人会使用同样的问题来绊倒这个问题.检查你的驱动器空间!:)
小智 7
我们遇到了一个非常类似的问题,mysql进程列表显示几乎所有连接都处于"查询结束"状态.我们的问题还与复制和编写binlog有关.
我们将sync_binlog变量从1更改为0,这意味着不是在每次提交时将binlog更改刷新到磁盘,而是允许操作系统决定何时将fsync()更新为binlog.这完全解决了我们的"查询结束"问题.
根据Mats Kindahl的这篇文章,写入binlog将不会成为MySQL 5.6版本中的问题.
| 归档时间： |
|
| 查看次数： |
25048 次 |
| 最近记录： |