akelsey
@akelsey

Низкая производительность восстановления из дампа (slow insert) MySQL 5.7, есть предложения?

Нужна помощь гуру MySQL, после переноса проекта с одного сервера на другой - столкнулся с проблемой производительности.
Отличия конфигураций,
было (слева): оптерон, 16Гб ОЗУ, супермикро платформа, 1ТБ 7200 хдд 64мб кэш, ubuntu 14.04, mysql 5.5
Стало (справа): зион, 32гб ОЗУ, супермикро, 1ТБ 7200, ubuntu 18.04, mysql 5.7.
видео на ютубе

my.cnf

[mysqld_safe]
nice = 0
socket = /var/run/mysqld/mysqld.sock

[mysqld]
sql-mode =
log_error = /var/log/mysql/error.log
skip-external-locking

sync_binlog = 0
default-storage-engine = innodb
innodb_buffer_pool_size = 24G
innodb_file_per_table = 1
innodb_log_file_size = 640M
innodb_flush_log_at_trx_commit = 2
innodb_flush_log_at_timeout = 0
innodb_flush_method = O_DIRECT
innodb_doublewrite = 1
innodb_write_io_threads = 4
innodb_read_io_threads = 4
innodb_purge_threads = 0
bulk_insert_buffer_size = 512M

performance_schema_max_thread_instances = 1000
thread_stack = 196608

max_allowed_packet = 16M
max_connections = 256
max_heap_table_size = 512M
max_join_size = 1000000

long_query_time = 1
expire_logs_days = 10
max_binlog_size = 100M
key_buffer_size = 16M
thread_stack = 256K
thread_cache_size = 16M

query_cache_type = 1
query_cache_limit = 1G
query_cache_size = 64M

table_definition_cache = 4096
table_open_cache = 4096
tmp_table_size = 256M
tmpdir = /var/lib/mysql/tmp
innodb_tmpdir = /var/lib/mysql/tmp

innodb_flush_method = O_DIRECT
transaction-isolation = READ-COMMITTED

# read_buffer_size = 2M
# read_rnd_buffer_size = 2M
# sort_buffer_size = 2M
# join_buffer_size = 2M

log-queries-not-using-indexes

table_open_cache = 16384
table_open_cache_instances = 16384
thread_cache_size = 16

/var/lib/mysql/tmp => ramdrive tmpfs 2GB

запись 1Gb файла через DD быстрее на зионе, во всем быстрее - но INSERTы просто никакие.
База в 234М на старом сервере восстанавливается за 1:52, на новом 4:42 - в 2.5 раза (и это в лучшем случае, обычно до 8 минут занимает ристор).

Есть идеи как это подтюнить?

UPD:
Правильно ли я рассуждаю. Большой файл создается чуть быстрее. Т.е. производительность в целом диска даже выше предыдущего.
При попытке восстановить базу - происходит много операций INSERT, это логично, но по ощущениям MySQL слева - делает это веселее в разы, т.е. такое чувство что какого-то кэша недостаточно на MySQL 5.7 справа, и он постоянно комитит на диск каждый инсерт.
Как бы сделать так что б он запихивал все в темповую табличку. И потом комитил в базу.
Интересно что в /var/lib/mysql/tmp я вообще не вижу файлов.

UPD2:
Т.к. все нужно для битрикса, добавил теги, и примеры старого сайта и нового. Просьба обратить внимание на медленную запись даже на самом сайте:
старый сайт
5cebe128a21ed808853360.png
новый сайт
5cebe110315b2384840864.png
  • Вопрос задан
  • 66 просмотров
Решения вопроса 1
akelsey
@akelsey Автор вопроса
Сам отвечу себе.
Убил кучу времени. Тестировал IOPSы, даже переустановил хостерскую сборку OS, на чистую ОС от вендора (Ubuntu 18.04).
Итог, я накидаю тегов что бы гуглилось: Медленные INSERT, Медленная запись MySQL Ubuntu 18.04 из-за:
apt install cpufrequtils
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils
sudo systemctl disable ondemand

Результаты тоже не супер-пупер пока, но это уже победа (запись в 2.5 раза!):
5ced93f80469a284852060.png
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
19 авг. 2019, в 01:32
3000 руб./за проект
18 авг. 2019, в 22:47
35000 руб./за проект
18 авг. 2019, в 21:29
1500 руб./за проект