我们最近在一台需要对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
MySQL是一个多线程服务。如果它一次处理多个查询,消耗多个 CPU 内核(在 top 的 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,也许还需要显示引擎 INNODB 状态来捕获在这种情况下消耗 CPU 周期的内容。