Кулер – тоже вертолет, но маленький. (Неизвестный автор)

Тест производительности MySQL: MySQL 5.7 против MySQL 8.0

7 мин для чтения
FavoriteLoadingДобавить в избранное
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (Пока оценок нет)
Загрузка...
4 февраля 2019
Тест производительности MySQL: MySQL 5.7 против MySQL 8.0
MySQL 8.0 принес огромные изменения и модификации, которые были выдвинуты Oracle MySQL Team. Физические файлы были изменены. Например, * .frm, * .TRG, * .TRN и * .par больше не существуют. Было добавлено множество новых функций, таких как CTE (общие табличные выражения), оконные функции, невидимые индексы, регулярные выражения (или регулярные выражения) – последнее было изменено и теперь обеспечивает полную поддержку Unicode и является многобайтовой безопасностью. Словарь данных также изменился. Теперь он включен в словарь транзакционных данных, в котором хранится информация об объектах базы данных. В отличие от предыдущих версий, словарные данные хранились в файлах метаданных и нетранзакционных таблицах. Безопасность была улучшена с новым дополнением caching_sha2_password, который теперь является аутентификацией по умолчанию, заменяющей mysql_native_password, и предлагает большую гибкость, но ужесточенную защиту, которая должна использовать либо защищенное соединение, либо незашифрованное соединение, поддерживающее обмен паролями с использованием пары ключей RSA.

Со всеми этими классными функциями, улучшениями, улучшениями, которые предлагает MySQL 8.0, наша команда заинтересовалась, чтобы определить, насколько хорошо работает текущая версия MySQL 8.0, особенно учитывая, что наша поддержка версий MySQL 8.0.x в ClusterControl находится в процессе (так что следите за обновлениями). на этом. В этом посте не будут обсуждаться возможности MySQL 8.0, но мы намерены сравнить его производительность с MySQL 5.7 и посмотреть, как она улучшилась.

 

Настройка сервера и среды

Для этого теста мы намерены использовать минимальную настройку для производства с использованием следующей среды AWS EC2:

  • Тип экземпляра: t2.xlarge instance
  • Хранилище: gp2 (SSD-хранилище с минимальной 100 и максимальной 16000 IOPS)
  • vCPUS: 4
  • Память: 16 ГБ
  • MySQL 5.7 версия: MySQL Community Server (GPL) 5.7.24 Версия
  • MySQL 8.0: MySQL Community Server – GPL 8.0.14

Есть несколько переменных, которые мы установили для этого теста, а именно:

  • innodb_max_dirty_pages_pct = 90 ## Это значение по умолчанию в MySQL 8.0.
  • innodb_max_dirty_pages_pct_lwm = 10 ## Это значение по умолчанию в MySQL 8.0
  • innodb_flush_neighbors = 0
  • innodb_buffer_pool_instances = 8
  • innodb_buffer_pool_size = 8GiB

 

Остальные переменные, устанавливаемые здесь для обеих версий (MySQL 5.7 и MySQL 8.0), уже настроены ClusterControl для своего шаблона my.cnf.

Кроме того, пользователь, которого мы здесь использовали, не соответствует новой аутентификации MySQL 8.0, которая использует caching_sha2_password. Вместо этого обе версии сервера используют mysql_native_password, а переменная innodb_dedicated_server имеет значение OFF (по умолчанию), что является новой функцией MySQL 8.0.

Чтобы упростить жизнь, мы настроили узел версии MySQL 5.7 Community с ClusterControl с отдельного узла, затем удалили узел в кластере и выключили узел ClusterControl, чтобы сделать узел MySQL 5.7 бездействующим (без трафика мониторинга). Технически, оба узла MySQL 5.7 и MySQL 8.0 неактивны, и через них никакие активные соединения не проходят, так что это по сути чистый тест бенчмаркинга.

 

Используемые команды и сценарии

Для этой задачи sysbench используется для тестирования и моделирования нагрузки для двух сред. Вот следующие команды или сценарий, используемые в этом тесте:

sb-prepare.sh

#!/bin/bash

  
 host=$1 
 #host192.168.10.110 
 port=3306 
 user='sysbench' 
 password='@MysqP@66w0rd' 
 table_size=500000 
 rate=20 
 ps_mode='disable' 
 sysbench /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --threads=1 --max-requests=0 --time=3600 --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --tables=10 --report-interval=1 --skip-trx=on --table-size=$table_size --rate=$rate --db-ps-mode=$ps_mode prepare 

 

sb-run.sh

#!/usr/bin/env bash

 host=$1 
 port=3306 
 user="sysbench" 
 password="@MysqP@66w0rd" 
 table_size=100000 
 tables=10 
 rate=20 
 ps_mode='disable' 
 threads=1 
 events=0 
 time=5 
 trx=100 
 path=$PWD 
  
 counter=1 
  
 echo "thread,cpu" > ${host}-cpu.csv 
  
 for i in 16 32 64 128 256 512 1024 2048; 
 do 
  
     threads=$i 
  
     mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log 
     tmpfile=$path/${host}-tmp${threads} 
     touch $tmpfile 
     /bin/bash cpu-checker.sh $tmpfile $host $threads & 
  
     /usr/share/sysbench/oltp_read_write.lua --db-driver=mysql --events=$events --threads=$threads --time=$time --mysql-host=$host --mysql-user=$user --mysql-password=$password --mysql-port=$port --report-interval=1 --skip-trx=on --tables=$tables --table-size=$table_size --rate=$rate --delete_inserts=$trx --order_ranges=$trx --range_selects=on --range-size=$trx --simple_ranges=$trx --db-ps-mode=$ps_mode --mysql-ignore-errors=all run | tee -a $host-sysbench.log 
  
     echo "${i},"`cat ${tmpfile} | sort -nr | head -1` >> ${host}-cpu.csv 
     unlink ${tmpfile} 
  
     mysql -h $host -e "SHOW GLOBAL STATUS" >> $host-global-status.log 
 done 
  
 python $path/innodb-ops-parser.py $host 
  
 mysql -h $host -e "SHOW GLOBAL VARIABLES" >> $host-global-vars.log 

 

Таким образом, скрипт просто подготавливает схему sbtest и заполняет таблицы и записи. Затем он выполняет чтение/запись нагрузочных тестов, используя скрипт /usr/share/sysbench/oltp_read_write.lua. Сценарий сбрасывает глобальное состояние и переменные MySQL, собирает данные об использовании процессора и анализирует операции строки InnoDB, обработанные сценарием innodb-ops-parser.py. Затем сценарии генерируют файлы * .csv на основе выгруженных журналов, которые были собраны во время теста, затем мы использовали электронную таблицу Excel, чтобы сгенерировать график из файлов * .csv.

Теперь перейдем к результатам графика!

 

Операции со строками в InnoDB

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

 

В основном здесь мы извлекли только строковые операции InnoDB, которые выполняют выбор (чтение), удаление, вставку и обновление. Когда количество потоков увеличивается, MySQL 8.0 значительно превосходит MySQL 5.7! Обе версии не имеют каких-либо конкретных изменений конфигурации, но только заметные переменные, которые мы установили. Таким образом, обе версии в значительной степени используют значения по умолчанию.

Интересно, что в отношении заявлений MySQL Server Team о производительности операций чтения и записи в новой версии графики указывают на значительное улучшение производительности, особенно на сервере с высокой нагрузкой. Представьте разницу между MySQL 5.7 и MySQL 8.0 для всех операций с строками InnoDB, есть большая разница, особенно когда количество потоков увеличивается. MySQL 8.0 показывает, что он может работать эффективно независимо от его рабочей нагрузки.

 

Обработанные транзакции

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

 

Как показано на графике выше, производительность MySQL 8.0 снова показывает огромную разницу во времени, необходимом для обработки транзакций. Чем ниже, тем лучше он работает, а значит быстрее обрабатывать транзакции. Обработанные транзакции (второй график) также показывают, что оба числа транзакций не отличаются друг от друга. Это означает, что обе версии выполняют почти одинаковое количество транзакций, но отличаются тем, насколько быстро они могут завершиться. Хотя мы могли бы сказать, что MySQL 5.7 все еще может справляться с большими нагрузками при более низкой нагрузке, но можно ожидать, что реалистичная нагрузка, особенно в производстве, будет выше, особенно в самый загруженный период.

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

 

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

MySQL 8.0 показывает большие улучшения, особенно для чтения. Он показывает свою эффективность в записи особенно для серверов с высокой рабочей нагрузкой. Некоторая отличная дополнительная поддержка, которая влияет на производительность MySQL для операций чтения в версии 8.0, – это возможность создавать индексы в порядке убывания (или прямого сканирования индекса). Предыдущие версии имели только сканирование по возрастанию или обратному индексу, и MySQL должен был выполнять сортировку файлов, если требовался сортировка по убыванию (если нужна сортировка файлов, вы можете проверить значение max_length_for_sort_data). Нисходящие индексы также позволяют оптимизатору использовать многостолбцовые индексы, когда наиболее эффективный порядок сканирования смешивает восходящий порядок для некоторых столбцов и нисходящий порядок для других. Смотрите здесь для более подробной информации.

 

Ресурсы процессора

Тест производительности MySQL. MySQL 5.7 против MySQL 8.0

Во время этого бенчмаркинга мы решили использовать некоторые аппаратные ресурсы, в частности, загрузку процессора.

Позвольте нам сначала объяснить, как мы используем ресурсы ЦП здесь во время бенчмаркинга. sysbench не включает в себя коллективную статистику для аппаратных ресурсов, использованных или используемых в процессе, когда вы сравниваете базу данных. Из-за этого мы создали флаг, создав файл, подключившись к целевому хосту через SSH, а затем собрав данные из команды top в Linux и проанализировав их во время сна на секунду, а затем собрали снова. После этого возьмите самое значительное увеличение использования ЦП для процесса mysqld, а затем удалите файл флага.

Итак, давайте снова поговорим о графике, кажется, что он показывает, что MySQL 8.0 потребляет много ресурсов процессора. Больше, чем MySQL 5.7. Однако, возможно, придется иметь дело с новыми переменными, добавленными в MySQL 8.0. Например, эти переменные могут повлиять на ваш сервер MySQL 8.0:

  • innodb_log_spin_cpu_abs_lwm = 80
  • innodb_log_spin_cpu_pct_hwm = 50
  • innodb_log_wait_for_flush_spin_hwm = 400
  • innodb_parallel_read_threads = 4

 

Переменные с их значениями оставлены значениями по умолчанию для этого теста. Первые три переменные обрабатывают ЦП для повторного ведения журнала, что в MySQL 8.0 было улучшением из-за перепроектирования того, как InnoDB записывает в журнал REDO. Переменная innodb_log_spin_cpu_pct_hwm имеет привязку к процессору, что означает, что она будет игнорировать другие ядра процессора, если mysqld прикреплен только к 4 ядрам, например. Для параллельных потоков чтения в MySQL 8.0 добавлена новая переменная, для которой вы можете настроить количество используемых потоков.

Однако мы не стали углубляться в эту тему. Могут быть способы повышения производительности за счет использования функций, предлагаемых MySQL 8.0.

 

Заключение

Есть множество улучшений, которые присутствуют в MySQL 8.0. Результаты тестирования показывают, что произошло впечатляющее улучшение не только в управлении рабочими нагрузками чтения, но также и в высокой рабочей нагрузке чтения/записи по сравнению с MySQL 5.7.

Переходя к новым функциям MySQL 8.0, похоже, что он использует преимущества самых современных технологий не только в программном обеспечении (например, значительное улучшение для Memcached, удаленное управление для лучшей работы DevOps и т. д.), Но и также в оборудовании. Например, замена latin1 на UTF8MB4 в качестве кодировки символов по умолчанию. Это будет означать, что для этого потребуется больше дискового пространства, поскольку UTF8 требуется 2 байта для символов, не входящих в US-ASCII. Хотя в этом тесте не использовался новый метод аутентификации с caching_sha2_password, это не повлияет на производительность, если он использует шифрование. После аутентификации он сохраняется в кеше, что означает, что аутентификация выполняется только один раз. Поэтому, если вы используете одного пользователя для своего клиента, это не будет проблемой и будет более безопасным, чем предыдущие версии.

Поскольку MySQL использует самое современное аппаратное и программное обеспечение, он меняет свои переменные по умолчанию.

В целом, MySQL 8.0 эффективно доминирует над MySQL 5.7.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Просмотров: 80

Если статья понравилась, то поделитесь ей в социальных сетях:

Отправить ответ

Войти с помощью: 
avatar
  Подписаться  
Уведомление о

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!

badge
Обратный звонок 1
Отправить
galka

Спасибо! Ваша заявка принята

close
galka

Спасибо! Ваша заявка принята

close