【问题标题】:MySQL high CPU usage [closed]MySQL高CPU使用率[关闭]
【发布时间】:2010-11-19 21:56:31
【问题描述】:

最近我的服务器 CPU 一直很高。

CPU 负载平均为 13.91(1 分钟)11.72(5 分钟)8.01(15 分钟),我的网站流量仅略有增加。

运行 top 命令后,我看到 MySQL 正在使用 160% 的 CPU!

最近我一直在优化表,并切换到持久连接。这会导致 MySQL 使用大量 CPU 吗?

【问题讨论】:

  • 持久连接几乎总是不适合使用。
  • 我现在就把它们取下来看看有什么不同,因为我从来不记得一个月前 CPU 超过 2!
  • 服务器往往有多个核心。 CPU 使用率百分比是相对于一个核心计算的,换句话说,一个进程完全用完两个核心将有 200% 的 CPU 使用率。在这里,MySQL 使用了 100% 的一个内核和 60% 的另一个内核。这并不意味着所有 CPU 都用完了,很可能他至少还有两个空闲 CPU。
  • 高 CPU 几乎总是意味着查询效率低下。这通常通过更好的索引(尤其是“复合”)和/或重新制定查询来解决。

标签: mysql cpu-usage


【解决方案1】:

首先我想说你可能想要关闭持久连接,因为它们几乎总是弊大于利。

其次,我想说您想仔细检查您的 MySQL 用户,以确保任何人都不可能从远程服务器进行连接。这也是需要检查的主要安全事项。

第三,我想说您要打开 MySQL Slow Query 日志以密切关注任何需要很长时间的查询,并使用它来确保您没有任何查询锁定关键表太长了。

您可以检查的其他一些事情是在 CPU 负载较高时运行以下查询:

SHOW PROCESSLIST;

这将向您显示当前正在运行或正在运行的队列中的任何查询,查询是什么以及它正在做什么(如果查询太长,此命令将截断查询,您可以使用 SHOW FULL PROCESSLIST 查看完整查询文本)。

您还需要注意诸如缓冲区大小、table cachequery cacheinnodb_buffer_pool_size(如果您使用的是 innodb 表)之类的事情,因为所有这些内存分配都会影响可能导致 MySQL 占用 CPU 的查询性能。

您可能还想阅读以下内容,因为它们包含一些很好的信息。

使用分析器也是一个非常好的主意。您可以在需要时打开一些东西,它会显示您的应用程序正在运行哪些查询,是否有重复的查询,它们花费了多长时间等等。我一直在研究的一个例子是这样的PHP Profiler 但那里有很多。如果您使用的是 Drupal、Joomla 或 Wordpress 等软件,您需要在社区内四处询问,因为可能有可用的模块让您无需手动集成任何东西即可获取这些信息。

【讨论】:

  • 非常感谢,我删除了持久连接,然后设置了慢查询日志。我阅读了日志,大多数查询来自两个表,并且这些表没有被正确索引!只用了大约 10 分钟,但结果如下:CPU 负载平均为 0.48(1 分钟)0.95(5 分钟)2.42(15 分钟)非常感谢
  • 同样的问题,通过索引减慢进程的表来解决,谢谢 Steven 和 Juddling
  • @Juddling 您能否详细说明如何索引表?也许一些链接?我知道已经有一段时间了,但我对这件事真的很陌生。对不起,这个菜鸟问题
  • 记录慢查询帮助我找到了 CPU 利用率高的特殊问题。在我的例子中,它是一个 Wordpress 插件(ultimate-tag-cloud-widget),它在每次点击时都会做一个可怕的查询,只是为了显示流行的标签。这是一个很棒的插件,但需要通过某种缓存来增强(我最终对其进行了自定义以解决我的问题)。
  • 帮助解决不同问题的另一件事是修改上面提到的参数 innodb_buffer_pool_size。在试图找出 CPU 使用率高的原因时,我在某处读到 innodb_buffer_pool_size 至少应该是位于 /var/lib/mysql 中的文件 ibdata1 的大小。当 InnoDB 能够驻留在内存中时,它的工作效率似乎要高得多。这在某些情况下可能很难做到,因为 ibdata1 可能很大!还建议在某个地方确保 innodb_log_buffer_size 是 innodb_buffer_pool_size 大小的 25%。
【解决方案2】:

如果你在谷歌上搜索 MySQL 高 CPU 使用率或负载,这是最重要的帖子,我将添加一个额外的答案:

2012 年 7 月 1 日,在当前 UTC 时间中添加了闰秒,以补偿由于潮汐而导致的地球自转缓慢。在运行 ntp(或 ntpd)时,这一秒被添加到您的计算机/服务器的时钟中。 MySQLd 在某些操作系统上似乎不喜欢这个额外的秒数,并且会产生高 CPU 负载。快速修复是(以 root 身份):

$ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start

【讨论】:

  • 由于原帖是大约3年前的,我怀疑这是原帖者问题的原因。但这是我的问题的原因,刚刚救了我 - 所以谢谢!更多信息:blog.mozilla.org/it/2012/06/30/…
  • 在 Ubuntu 12.04 上对我来说同样的问题和解决方案。解决步骤略有不同: service ntp stop && date -s "date" && service ntp start MySQL CPU 使用率立即从 50 - 100% 下降到 0 - 1%
  • 可以执行此操作以确保吗?我的意思是,即使不是原因,运行它是否安全?
  • 2015 年 7 月 1 日 - 我刚刚在运行 Amazon Linux 的当前 AWS EC2 服务器上遇到了这个闰秒错误。在此配置上使用 sudo service ntpd stop
  • 这个解决方案+1。我的 MySQL 无缘无故地以 50-60% 的速度运行了几个月,在应用此解决方案后,它下降到现在的 0.0-0.3%,这是它应该的样子。非常感谢。
【解决方案3】:

如果此服务器对外界可见,则值得检查它是否有大量来自外界的连接请求(即试图闯入它的人)

【讨论】:

  • 不确定为什么这会引起匿名投票,因为这在过去是某些系统的原因。
  • 我认为否决票是因为让 MySQL 对外界可见并不是一个好主意。
  • @MikeKulls 不,这不是一个好主意,因为它会成为很多人尝试进入的目标,这会导致 CPU 负载很高 - 因此我的回答是可能的原因之一.
  • 我讨厌有人投了反对票就走了!
  • +1,因为这绝对是 MySQL 具有高 CPU 使用率的正当理由,任何想要回答这个问题的人都确实需要这些信息!
猜你喜欢
  • 1970-01-01
  • 2020-03-31
  • 2018-09-14
  • 1970-01-01
  • 2020-08-25
  • 1970-01-01
  • 2022-06-19
  • 1970-01-01
相关资源
最近更新 更多