LINUX.ORG.RU
решено ФорумAdmin

MySQL импортирует дамп под Linux в 13 раз медленнее, чем под macOS

 ,


0

1

Имеем дамп базы MySQL в виде dump.sql, который импортируем в чистую, только что созданную БД.

Так вот, в macOS импорт *.sql-дампов работает значительно (в разы - см. ниже) быстрее, чем под Linux.

Ситуацию эту наблюдаю уже не первый год, и принципиально она не меняется при смене версий MySQL, железа, дистрибутива, дампов и т.д.: разрыв от случая к случаю меняется (разное железо, разные дампы и т.д.), но мак всё равно значительно выигрывает минимум вдвое.

Для простоты и наглядности выбрал два основных конфига и провел тест на дампе, с которым работаю сейчас:

Мак: ноут Macbook Pro mid-2014, Core i5-4278U (2 ядра, 2.6GHz), SSD, файловая система HFS+,

Linux: десктоп с Core i7-8700 (6 ядер, 3.2 GHz), диск - NVMe, файловая система XFS.

Строго говоря, есть разница в версиях MySQL: сейчас на Linux стоит Percona 8.0.20-11, на маке - MySQL 5.7.29 (из репов Homebrew), но, повторюсь, это погоды не делает - когда стояли одинаковые версии, ситуация была такой же.

Время импорта одного и того же дампа (размер - 308М):

Мак - полторы минуты:

real    1m30.316s
user    0m17.720s
sys     0m1.150s

Linux - более двадцати минут:

real    20m14.797s
user    0m9.236s
sys     0m2.626s

При импорте под маком процесс MySQL нагружает CPU на 70-80%, под линуксом - на 15-25% (оба показателя - на глаз через htop).

ИМХО, разница слишком большая, чтобы подозревать железо - следовательно, дело должно быть в конфигах.

На какие опции конфигов стоит посмотреть? Что ещё, кроме конфигов, может влиять?

Буду рад любым идеям.

Разницу в 20 раз на одном и том же дампе, вообще фигзнаеет что может объяснить, но справедливости ради Persona это не MySQL, MySQL ныне под крылом оракла и может иметь каенить хитрые плюшки, но опять же здравый смысл подсказывает что не на x20

Я тут что вспомнил, стандартный линуксовый mysql dump/restore оч долго не обновлялся и был достаточно не эффективным в плане скорости, я видел несколько наколенных передлок его в многопоточность на баше, ты что использовал для рестора в обоих вариантах?

sparks ★★ ()
Последнее исправление: sparks (всего исправлений: 1)
Ответ на: комментарий от sparks

У меня как раз всё стандартно: дамп через mysqldump > file.sql, импорт через mysql dbname -u root < file.sql.

p.s. Вообще, восстановление дампа - это просто самый наглядный и измеримый пример, а так разница ощущается во всех операциях, связанных с записью (в том числе при изменении структуры БД).

aix27249 ()

По-умолчанию в мускуле включено, что он после каждой вставки должен сбросить данные на диск, а уже потом сообщать, что вставка завершена, чтобы при пропадании питания данные не пропали. Чувак на маке просто включил более быстрый режим, для разработки самое оно.

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

Я и делал это раньше, но обилие отличающихся опций сбивало с толку.

Проделал ещё раз, и на этот раз повезло - нашел: дело оказалось в innodb_use_native_aio: на маке стояло OFF, а на linux - ON.

Прописал в конфиг /etc/mysql/my.cnf innodb_use_native_aio = OFF и всё стало резко хорошо:

real    1m10.677s
user    0m5.828s
sys     0m1.615s

Однако согласно документации, эта штука - фича, и с ней должно быть быстрее.

Пойду разбираться, почему так (возможно, дело в неоптимальном количестве потоков?)

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

В общем, да: это было кривое количество потоков. Каким-то боком в конфиги затесалось innodb_write_io_threads = 64.

Поставил innodb_write_io_threads = 12 (это количество логических ядер у проца), и всё стало так же хорошо, как и при innodb_use_native_aio = OFF.

В целом, основную задачу я решил, всем спасибо, но всё равно у меня остались вопросы:

  • Зачем нужно innodb_use_native_aio = ON и шаманство с подбором количества потоков, если его отключение дает такие же результаты? В каких случаях будет разница?

  • Как подбирать корректное значение для innodb_write_io_threads и innodb_read_io_threads? На моем компе оптимальным выглядит число, совпадающее с количеством логических ядер в системе, но нигде не могу найти документации на этот счет.

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

Ну еще могу пованговать, что дело может быть в innodb_autoextend_increment или file-per-table или каких-то других опциях, связанных с тем, как расширяется размер файлов данных.

goingUp ★★★★★ ()