☰

在繁重的 mysql 服务器上，内存使用率很高，但 CPU 使用率应该这么低吗？

tag-icon • tag-icon ubuntu mysql performance memory cpu-usage
在繁重的 mysql 服务器上，内存使用率很高，但 CPU 使用率应该这么低吗？

我使用的是 ubuntu server 12.04 x64。服务器通过 apache web 服务器（它的轻量级接口）接收大量对 mysql 的请求。从 mysql 统计数据中，我看到从早上 8 点到晚上 9 点大约有 250 个查询/秒。晚上服务器几乎没有使用。RAM 大部分由 mysql 使用（根据 mysqloptimizer，MySQL 最大 RAM 使用量为 25GB）。Top 证实了这一点 - mysql 使用了大约 77% 的 RAM。

数据库大小约为 20GB。受攻击最严重的一个表大约有 1-2 百万条记录（主要是来自几个表的 id 字段以及一些 smallints 计数器）。

我附加了一些对我来说有趣的部分的图像（第二个内存图像显示了服务器重启后的内存行为）。在此处输入图片描述

在观看 munin 时我想到几个问题：

  1. 为什么内存使用量apps实际上从未下降？它不应该在服务器没有流量的晚上减少吗？

  2. 以某种方式进行调整以为缓存提供更多的内存空间不是更好吗？

  3. 为什么 RAM 已满但 CPU 使用率却如此低？

  4. 不活跃记忆的水平也在上升，这让我有点担心。

这些问题之所以出现，是因为流量偶尔会在短时间内大幅增加，而此时服务器无法响应大量请求。但此时 RAM/CPU 甚至磁盘延迟不会增加太多，甚至可能增加一点点。这些流量增加是不可避免的，但我不确定用 stringer one 替换服务器是否可以解决这个问题，或者可能只是增加更多 RAM（因为 CPU 使用率最低）？

如果这个问题无法回答--抱歉。

编辑：# # MySQL 数据库服务器配置文件。# # 您可以将其复制到以下位置之一：# - “/etc/mysql/my.cnf”设置全局选项，# - “~/.my.cnf”设置用户特定选项。# # 可以使用程序支持的所有长选项。# 使用 --help 运行程序以获取可用选项列表，并使用 # --print-defaults 查看程序实际理解和使用哪些选项。# # 有关说明，请参阅 #http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
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
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address       = 127.0.0.1

#
# * Fine Tuning
#
key_buffer      = 64M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 64
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP
max_connections        = 400
table_cache            = 6000
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 1M
query_cache_size        = 32M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error logging goes to syslog due to /etc/mysql/conf.d/mysqld_safe_syslog.cnf.
#
# Here you can see queries with especially long duration
slow_query_log = 0
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 20
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem

innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size = 512M
innodb_buffer_pool_size = 24G
bulk_insert_buffer_size = 256M
innodb_open_files = 6000
innodb_flush_log_at_trx_commit = 2
innodb_lock_wait_timeout = 50
innodb_file_io_threads = 4
thread_cache_size = 64
thread_concurrency = 12
query_cache_size = 64M
query_cache_limit = 2M

max_sp_recursion_depth = 50
thread_stack = 384K

tmp_table_size = 64M
max_heap_table_size = 64M
key_buffer_size = 32M

event_scheduler = ON

lower_case_table_names = 1

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition

[isamchk]
key_buffer      = 16M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

答案1

数据库（99%）会缓存所有可以缓存的内容。缓存很有用。它可以让数据处理得更快。您希望数据库服务器占用所有可以占用的内存，除非迫不得已，否则绝不释放内存。

除非你要求它缓存数据（比如在查询中），否则它不会缓存数据。也许有工具可以让 MySQL 预先缓存数据，但我不知道。较新的数据库产品开始获得大量内存功能，你可以选择某些数据来总是存在于记忆中。

CPU 使用率与 RAM 使用率无关。您的查询可能非常轻量，例如每次都只命中索引的细粒度 SELECT。换句话说，数据库将为您提供驻留在 RAM 中的缓存数据，因此需要完成的 CPU 工作很少（例如调度 I/O 以从磁盘检索和处理数据）。

在我看来，这是一个非常健康且性能快速的数据库。实际上没有任何问题。如果您有可用内存，那么这只意味着数据库不需要缓存更多数据，因为它从未被请求过。

编辑：您已将 InnoDB 池限制为 24GB，这非常好，因为您的数据库是 20GB。如果数据库增加，则注意增加缓冲池大小。您还提到您担心可用内存的减少 - 只有在数据库以外的其他进程正在消耗内存时才应该担心。数据库服务器不会超出您限制的范围。

相关内容