Почему после переноса сервера MYSQL грузит процессор на 200%?

Question

[Константин Хаиров]

Всем привет.

Перенес сайт с VDS на физический сервер. Разница только в процессоре. Там стоял процессор

Intel(R) Xeon(R) CPU X5660 @ 2.80GHz (2 ядра)

на физическом стоит intel core i3 8100 3,60 GHz 4 ядра

Озу добавилось. Раньше было 3 ГБ теперь 8

Но вот какое дело, перенес все на новый сервер включая конфиги. Там база данных работала и грузила процессор на 50-60% при том на сайте все кешировалось за счет этого запросов было меньше. Сейчас, после переноса на сервер все также кешируется но теперь процессор грузится на 200% и страницы с 2-3 sql запросами в бд (простые 2 select where id = 121212) проходит за 15-20 секунд....

При переносе заметил что не было индексов в больших таблицах, все восстановил, думал возможно в этом проблема, но это не помогло. В чем еще может быть дело? Неужели процессор не сможет этот справится с сайтом (20к в сутки) в среднем одновременно онлайн 100-150 человек.

ОС: Centos 7

КОНФИГ:

Конфиг MariaDB

[mysqld]
skip-external-locking
key_buffer_size = 32K
max_allowed_packet = 8M
table_open_cache = 56
max_connections = 512
sort_buffer_size = 128K
read_buffer_size = 256k
read_rnd_buffer_size = 256k
myisam_sort_buffer_size = 2M
thread_cache = 5
thread_cache_size = 2
query_cache_min_res_unit = 8
query_cache_size = 0
query_cache_type = 1
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
default-storage-engine = MyISAM
##########################
max_allowed_packet = 16M
key_buffer_size = 16M
innodb_buffer_pool_size = 512M
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
max_connections = 512
query_cache_size = 0
long_query_time = 1
expire_logs_days = 10
max_binlog_size = 100M
tmp_table_size = 32M
max_heap_table_size = 32M
sort_buffer_size=2M # from 1M to reduce sort_merge_passes
read_buffer_size=128K # from 1M to reduce handler_read_next RPS
read_rnd_buffer_size=256K # from ? may reduce handler_read_rnd_next RPS
join_buffer_size=128K # from 1M for join row pointers

#slow_query_log=1
#slow_query_log_file=/var/log/mysql-slow-queries.log

[myisamchk]
key_buffer_size = 32M
sort_buffer_size = 32M
read_buffer = 32M
write_buffer = 32M

Comments

[Константин Хаиров]

Иван, SSD 120GB Lexar

[wagoodoogoo]

цифра в 200% не кого не смутила?

[PrAw]

wagoodoogoo, 2 ядра грузит

[PrAw]

SHOW PROCESSLIST что говорит?
проблема может быть чуть более интересной, может что-то еще с БД работает параллельно
iotop тоже посмотреть.

[Андрей]

Константин Хаиров, thread_concurrency = 4 поставь 8.
выполни mysqlcheck --auto-repair --optimize --all-databases
и смотри mytop и slow_query_log=1
slow_query_log_file=/var/log/mysql-slow-queries.log

[Константин Хаиров]

Иван, Бекап свежий делал через mysqldump. Сразу сделал и сразу развернул на новом сервере.

[Константин Хаиров]

Андрей, Сейчас попробую.

[Александр Филиппенко]

А query_cache_size = 0 это нормально разве?

Answer 1

[Константин Хаиров]

Проблему решил взяв конфиг от слабенького сервера и увеличил значения в 4 раза. В конфиге расчет на сервер с 1 ядром и 512 МБ.

Answer 2

[Vitaly Karasik]

Есть всякие идеи по оптимизации, например

innodb_buffer_pool_size = 512M

стоит дать 5G (при условии что большинство таблиц InnoDB).

Но объяснить что случилось при переносе трудно без статисти\конфигов со старого сервера.
Возможные варианты:
- изменилась конфигурация вебсервера или на новом сервере нету кеш-сервера и поэтому больше запросов к базе (есть мониторинг базы?)
- изменился конфиг базы