Ubuntu

CPU 使用率是否應該如此低,而重型 mysql 伺服器上的記憶體使用率很高?

  • August 28, 2013

我正在使用 ubuntu 伺服器 12.04 x64。伺服器通過 apache web 伺服器(它是輕量級介面)接收大量對 mysql 的請求。從 mysql stats 我看到從上午 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/

數據庫(嗯,其中 99%)會記憶體所有可以記憶體的東西。記憶體很好。它使事情變得更快。您希望您的數據庫伺服器盡可能地使用所有記憶體,並且除非必須,否則永遠不要釋放它。

除非您要求它(例如在查詢中),否則它不會記憶體內容。也許有工具可以使 MySQL 預記憶體數據,但我不知道。較新的數據庫產品開始獲得大量記憶體功能,您可以在其中選擇某些數據始終存在於記憶體中。

CPU 使用率與 RAM 使用率無關。您的查詢可能非常輕量級,例如每次都會命中索引的細粒度 SELECTS。換句話說,數據庫將為您提供駐留在 RAM 中的記憶體數據,因此需要完成的 CPU 工作非常少(例如調度 I/O 以從磁碟檢索和處理數據)。

對我來說,這看起來像是一個非常健康和快速執行的數據庫。真的一點問題都沒有。如果您有空閒記憶體,那麼這僅意味著數據庫不需要記憶體更多數據,因為它從未被請求過。

編輯:您已將 InnoDB 池限制為 24GB,這非常好,因為您的數據庫為 20GB。如果數據庫增加,請注意增加緩衝池大小。您還提到您擔心可用記憶體的減少 - 只有當數據庫以外的其他程序正在使用它時,這才應該是一個問題。數據庫伺服器的增長不會超出您的限制。

引用自:https://serverfault.com/questions/534434