mysql - MySQL CPU 时间本来就这么长吗？

Question

我们最近在一台新服务器上运行了大量复杂的脚本，需要对 MySQL 进行大量监控。服务器一次最多只运行 20 小时。但不管怎样，Mysql的cpu使用时间只是一直持续下去。

我猜测这是注定会发生的，因为它是一个持续运行的服务，但只是想确认这一点。

根据top，mysql已经运行了380:09.23。

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1697 mysql     20   0 2687376 504752  10036 S  82.3  6.3 380:09.23 mysqld

Answer 1

MySQL 是一个多线程服务。如果它一次处理多个查询，消耗多个 CPU 核心(在顶部的 CPU 列中显示为超过 100%)，则在 TIME+ 列中为这一秒的物理时间添加超过一秒。

您可以通过发出以下命令来监视当前在复合 MySQL 进程中运行的线程

SHOW PROCESSLIST;

在 mysql 控制台中(即您通常向此服务器发出 SQL 语句的位置)。

添加:

我有一个低吞吐量的 MySQL 5.6 实例，自 2018 年 1 月 4 日以来就没有重新启动过。它在 debian、裸机 ARM 上运行，通常不会有很多空闲连接挂起(我现在看到两个) )。从那时起它已经消耗了大约 2225 分钟的 CPU 时间:

$ ps -eo pid,lstart,time,cmd | grep mysql
 3895 Thu Jan  4 23:09:11 2018 1-13:04:45 /usr/sbin/mysqld ...

我还刚刚进行了两次民意调查，它在 140 分钟的物理时间中增加了 15 秒的 CPU 时间:

$ date; ps aux | grep mysql
Tue Oct  1 16:37:16 UTC 2019
mysql     3895  0.2 10.7 439512 223352 ?       Sl    2018 2224:37 /usr/sbin/mysqld

$ date; ps aux | grep mysql
Tue Oct  1 18:57:50 UTC 2019
mysql     3895  0.2 10.7 439512 223352 ?       Sl    2018 2224:55 /usr/sbin/mysqld

因此，至少在这种情况下，在没有执行实际工作的情况下添加 TIME+ 指标是不正常的。

我怀疑在虚拟环境中如果没有相应的 %CPU，TIME+ 可能会增加，但是您仍然需要监视 PROCESSLIST，也许还需要 SHOW ENGINE INNODB STATUS 来捕获在这种情况下消耗 CPU 周期的内容。