LINUX.ORG.RU
ФорумAdmin

MySQL и высокая нагрузка на процессор

 , ,


1

1

Всем доброго времени суток. Ситуация следующая.

Имеется сервер (VDS):

Процессор 4 x 2,7 ГГц

RAM 1G

Стоит Percona MySQL Server 5.7

Все таблицы InnoDB (одна из таблиц весит правда 45 гигов - от этого пока что не избавиться). Всё это переехало с другого сервера, на котором было всё нормально (сам сервер такой-же, но MySQL Server стоял 5.5) Так вот - на новом сервере процессор постоянно загружен именно процессами скуля. Вот конфиг скуля

[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
explicit_defaults_for_timestamp
bind-address = 10.8.0.7
log-error    = /var/log/mysql/error.log
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES
symbolic-links=0
character-set-server=utf8
collation-server=utf8_general_ci
init-connect="SET NAMES utf8"
skip-name-resolve
max_connections = 20
interactive_timeout=60
wait_timeout=60
innodb_file_per_table = 1
table_open_cache = 400
innodb_open_files = 1024
key_buffer_size = 32M
max_allowed_packet = 1073741824
sort_buffer_size = 32M
read_buffer_size = 256K
read_rnd_buffer_size = 128M
query_cache_limit = 1M
query_cache_size = 128M
query_cache_type = 1
thread_cache_size = 64
max_heap_table_size = 128M
tmp_table_size = 256M
innodb_buffer_pool_size=512M
innodb_buffer_pool_instances = 4
innodb_log_file_size = 128M
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 0
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_stats_on_metadata = 0
general_log_file	= /var/log/mysql/mysql.log
general_log		= 1
long_query_time=1
slow_query_log=1
slow_query_log_file=/var/log/mysql/log-slow-queries.log
log-queries-not-using-indexes

Вот графики CPU IDLE за последние 3 часа. С момента запуска вот такой «забор» постоянно. Вот скрин графиков нагрузки на процессор На прошлом сервере всё нормально было. Может кто подскажет? К сожалению, конфиг скуля со старого сервера недоступен.



Последнее исправление: kai_zer (всего исправлений: 1)

Стоит Percona MySQL Server 5.7
это переехало с <...> MySQL Server 5.5

копай в эту сторону. Сам замечал рост потребления памяти при переходе 5.5/5.6, но с чем связано - не помню.

anonymous
()
Ответ на: комментарий от kai_zer

Оперативки 1 гиг.

Если анонимус прав, глянь на размер свопа. Если сильно больше нуля, то где-то тут и проблема. Ещё обрати влимание на то, что показывает запрос «show processlist». Может, какой-то конкретный запрос стал работать не сильно быстро. Индексы точно так же перенеслись ?

AS ★★★★★
()
Ответ на: комментарий от AS

перенесено всё точно

Вручную сравнивал каждую таблицу (структура и индексы). show processlist - пустой почти всегда. SlowLog тоже пустой. Размер свопа - имеется ввиду своп системы? Или своп мускула?

Если своп самой операционки - свободно 700 метров из 1 гига.

kai_zer
() автор топика
Ответ на: перенесено всё точно от kai_zer

Если своп самой операционки - свободно 700 метров из 1 гига.

Самой операционки. Если там много уходит в своп, это может быть проблемой в скорости чего угодно. Но надо ещё посмотреть на buffers/cached. Если там тоже много, тогда своп, может, и не при чём: было бы надо, система бы от buffers/cached нужное откусила.

AS ★★★★★
()
Ответ на: комментарий от AS

Памть

Памяти ему предостаточно. Свободная память больше 70% и своп тоже свободен нормально.

Проблема именно в потреблении процессора.

Самое интересное - постоянно нагрузка скачет с одного ядра на другое. Сначала загружено одно ядро на пару часов. Потом отпускает и загружается другое.

Так все 4 ядра вперемешку.

kai_zer
() автор топика
Ответ на: Памть от kai_zer

Свободная память больше 70%

Это важно.

и своп тоже свободен нормально.

Это - не очень важно. Тут главное, что он занят. И вот тут вопрос. 70% свободно тогда чего ? Почему своп занимается в этом случае, хоть на сколько-то ?

Самое интересное - постоянно нагрузка скачет с одного ядра на другое

Тоже хороший вопрос. Один SQL-запрос врядли может быть распараллелен, но вот если все они на одном ядре исполняются, это непорядок.

Так, а что с дисковой подсистемой ? Что было, что стало ? В смысле, может оно и не имеет отношение к MySQL. То есть, это вопрос к драйверу: сколько там очередей, которые могут развеситься на разные ядра.

AS ★★★★★
()
Последнее исправление: AS (всего исправлений: 3)

Гиг памяти при 45-гиговых таблицах это просто несмешной йобаный пиздец.

svr4
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.