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

SHOW ENGINE INNODB状态 https://pastebin.com/raw/bEZG5GEc

SHOW GLOBAL STATUS（30.10.2018 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

尝试减少innodb_buffer_pool_size的来源：

innodb_buffer_pool_size=12G

成为：

innodb_buffer_pool_size=1G

Answer 2

当整个数据集都放入缓冲池中时，就无需等待I / O了，这通常是瓶颈，因为它比RAM慢得多。

因此，如果对已经存在于RAM（缓冲池）中的数据运行大量只读查询，那么约束资源就是CPU，因为它扫描并从RAM中搜索数据。这就是为什么您的CPU负载看起来如此之高的原因。它只是一直在忙着工作，因为它不必等待其他任何事情。

证据在“缓冲区池和内存”下处于InnoDB状态：

读取的页面数7814，创建的页面数70，记录的页面3805 7.32次/秒，0.00次创建/秒，3.55次/秒缓冲池命中率1000/1000，成年率0/1000，而不是0/1000

“已创建”统计信息是第一次必须加载到缓冲池中的页面数。之所以这么低，是因为实际上所有页面都已经在缓冲池中。

“命中率”是查询请求页面且页面已经在缓冲池中的次数，因此无需再次从磁盘加载页面。这是1000/1000，表示每次请求页面时都已经加载该页面。或至少有99.9％的时间。

按照建议调整缓冲池的大小之后，您可能已经重新启动了MySQL Server，这将驱逐缓冲池的内容。重新启动后，查询将从磁盘读取页面以将其还原到缓冲池，因此它们必须等待I / O。但是最终您将到达所有数据再次位于缓冲池中的位置，并且我预计您会看到CPU负载再次增加。

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

0.05次/秒，0.50次/秒，0.00次/秒，4970813.64次/秒

每秒查询率：

每秒平均查询量：748.944

这意味着每秒大约750个查询负责每秒读取近500万行。平均每个查询超过6,600行。那是

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

鉴于您的整个数据库只有150MB，这真是令人惊讶。

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

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

高MySQL CPU使用率（300-400％）

2 个答案: