Назад | Перейти на главную страницу

Должно ли использование ЦП быть таким низким, в то время как использование памяти велико на тяжелом сервере mysql?

Я использую ubuntu server 12.04 x64. Сервер получает множество запросов к mysql через веб-сервер apache (это легкий интерфейс). Из статистики mysql я вижу, что с 8:00 до 21:00 выполняется около 250 запросов в секунду. Ночью сервер практически не используется. RAM в основном используется mysql (согласно mysqloptimizer максимальное использование оперативной памяти MySQL составляет 25 ГБ). Топ подтверждает это - mysql использует около 77% оперативной памяти.

Размер базы данных составляет около 20 ГБ. Одна таблица, которая подвергается сильнейшей критике, содержит около 1-2 миллионов записей (в основном поля id из нескольких таблиц плюс несколько счетчиков smallints).

Я прикрепил изображения, иллюстрирующие интересующие меня части (вторые изображения памяти показывают поведение памяти после перезапуска сервера).

Во время просмотра мунина у меня возникло несколько вопросов:

  1. Почему в использовании памяти apps память практически не падает? Разве это не должно уменьшаться, например, ночью, когда на сервере нет трафика?

  2. Не лучше ли как-нибудь подправить, чтобы освободить место для кеша?

  3. Почему загрузка ЦП так низка, когда ОЗУ заполнено?

  4. Уровень неактивной памяти тоже повышается, что меня немного беспокоит.

Эти вопросы возникли из-за того, что иногда трафик значительно увеличивается на короткое время, и в эти моменты сервер не отвечает на большое количество запросов. Но в такие моменты ОЗУ / ЦП или даже задержка диска не сильно увеличивается, может быть, немного. Этот рост трафика неизбежен, но я не уверен, сделает ли это замена сервера на более строгий или, может быть, только добавит больше оперативной памяти (поскольку использование процессора минимально)?

Если на этот вопрос нет ответа - извините.

РЕДАКТИРОВАТЬ: # # Файл конфигурации сервера базы данных 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, но я понятия не имею. Новые продукты баз данных начинают получать множество функций в памяти, где вы можете выбирать определенные данные для всегда присутствовать в памяти.

Использование ЦП не связано с использованием ОЗУ. Ваши запросы могут быть чрезвычайно легкими, например, только мелкие запросы SELECTS, которые каждый раз попадают в индекс. Другими словами, база данных будет обслуживать кешированные данные, которые находятся в ОЗУ, поэтому потребуется очень мало работы ЦП (например, планирование ввода-вывода для извлечения и обработки данных с диска).

Для меня это выглядит как очень здоровая и быстро работающая база данных. На самом деле никаких проблем нет. Если у вас есть свободная память, это просто означает, что базе данных не нужно кэшировать больше данных, поскольку они никогда не запрашиваются.

РЕДАКТИРОВАТЬ: вы ограничили пул InnoDB до 24 ГБ, что отлично, поскольку ваша база данных составляет 20 ГБ. Если база данных увеличивается, позаботьтесь об увеличении размера буферного пула. Вы также упоминаете, что вас беспокоит уменьшение доступной памяти - это должно вызывать беспокойство только в том случае, если ее используют другие процессы, кроме базы данных. Сервер базы данных не вырастет сверх того, чем вы его ограничили.