mysql - MySQL CPU 使用率高 (300-400%)

Question

最近几天我的 MySQL CPU 使用率出现问题，平均 CPU 使用率为 300%。 MySQL 版本是 5.7，数据库有 ~150MB 非常感谢您的帮助。

服务器规范:

Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz
16GB DDR3

从 mysqladmin 登录

Uptime: 271  Threads: 6  Questions: 202964  Slow queries: 0  Opens: 311  
Flush tables: 1  Open tables: 254  Queries per second avg: 748.944

我的my.cnf

[mysqld_safe]
socket          = /var/run/mysqld/mysqld.sock
nice            = 0

[mysqld]
user            = mysql
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /var/run/mysqld/mysqld.sock
port            = 3306
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

sql_mode = STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

bind-address            = 127.0.0.1

key_buffer_size         = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
myisam-recover-options  = BACKUP
max_connections        = 2000

query_cache_limit       = 1M
query_cache_size        = 16M

log_error = /var/log/mysql/error.log

expire_logs_days        = 10
max_binlog_size   = 100M
query_cache_type=ON
query_cache_size=256M

innodb_buffer_pool_size=12G
innodb_log_buffer_size=128M
innodb_write_io_threads = 4
innodb_read_io_threads  = 4

mysqltuner日志 https://pastebin.com/raw/xv4FPjpe

findfragtables.sql 日志 https://pastebin.com/raw/TGP5qjtV

ulimit -a https://pastebin.com/raw/AeYKtqHH

显示引擎 INNODB 状态 https://pastebin.com/raw/bEZG5GEc

显示全局状态(2018 年 10 月 30 日 12:28 UTC+2) https://pastebin.com/raw/1zFsTYNf

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
mysql    15632  277  8.8 16271348 1447256 ?    Sl   13:58 169:28 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid

Answer 1

当您的整个数据集适合缓冲池时，就无需等待 I/O，这通常是瓶颈，因为它比 RAM 慢得多。

因此，如果您对 RAM(缓冲池)中已有的数据运行大量只读查询，则约束资源是 CPU，因为它会从 RAM 中扫描和搜索数据。这就是为什么你的 CPU 负载看起来如此高。它只是稳定地忙于工作，因为它不需要等待其他任何事情。

证据处于“BUFFER POOL AND MEMORY”下的 InnoDB 状态:

Pages read 7814, created 70, written 3805 7.32 reads/s, 0.00 creates/s, 3.55 writes/s Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000

“已创建”统计数据是必须首次加载到缓冲池中的页面数。它是如此之低，因为几乎所有页面都已经在缓冲池中。

“命中率”是查询请求页面并且该页面已经在缓冲池中的次数，因此无需再次从磁盘加载它。这是1000/1000，表示每次请求一个页面时，它就已经被加载了。或者至少 99.9% 的时间。

按照建议调整缓冲池大小后，您可能会重新启动 MySQL 服务器，这将逐出缓冲池的内容。重新启动后，您的查询将从磁盘读取页面并将其恢复到缓冲池，因此它们必须等待 I/O。但最终您将达到所有数据再次位于缓冲池中的程度，并且我预测您将看到 CPU 负载再次增加。

我还注意到，在您的 InnoDB 状态“ROW OPERATIONS”中:

0.05 inserts/s, 0.50 updates/s, 0.00 deletes/s, 4970813.64 reads/s

还有每秒的查询率:

Queries per second avg: 748.944

这意味着每秒大约 750 个查询可导致每秒读取近 500 万行。平均每个查询超过 6,600 行。这就是

我怀疑这是你的CPU负载过高的根本原因。您的查询平均会扫描很多页面，即使这些页面位于 RAM 中。

考虑到您的整个数据库只有 ~150MB，这非常令人惊讶。

您应该分析每个经常运行的查询，以确定是否有一些索引可以帮助缩小搜索范围，这样您就不必在每个查询中检查如此多的行。

您可能会喜欢我的演示How to Design Indexes, Really ，或者我展示它的视频:https://www.youtube.com/watch?v=ELR7-RdU9XU