Я тестирую базу данных Microsoft Azure для MySQL и столкнулся с проблемой производительности, которую я не понимаю.
Я запустил «базовый» сервер с 1 виртуальным ядром (2 ГБ ОЗУ, «стандартное хранилище»), что является их самым низким уровнем сервера. Я создал базу данных, таблицу и импортировал около 4 миллионов строк (30 ГБ) с помощью LOAD DATA INFILE. Прошло 56 минут.
Затем я запустил сервер с «оптимизацией памяти» с 8 виртуальными ядрами (80 ГБ ОЗУ, «хранилище премиум-класса»). Я повторил те же самые задачи и загрузил точно такой же файл. На этот раз на это ушло 7 часов 16 минут.
Лучше сервер, намного хуже производительность (по этой задаче) - не то, что я ожидал. Чтобы убедиться, что я не ошибся, я повторил описанные выше шаги, но снова получил почти те же результаты.
Я подозреваю, что проблема в том, что сервер с оптимизацией памяти имеет другие параметры сервера по умолчанию, чем базовый сервер, из-за чего эта задача выполняется медленнее (я не менял параметры по умолчанию, которые устанавливает Azure). Но я не уверен, какие параметры виноваты. Если у кого-то есть понимание этой проблемы, я был бы признателен.
Основные параметры сервера: http://pastebin.zone/wRniyPm6
Параметры сервера с оптимизацией памяти: http://pastebin.zone/phuDcZj4
Вот что, похоже, вызывает такое поведение:
По Документация по Azure, сервер базового уровня в Azure поставляется с «переменным» IOPS, тогда как сервер с оптимизацией памяти поставляется с фиксированным IOPS, который зависит от объема хранилища, назначенного серверу базы данных.
Мне было выделено 100 ГБ для сервера с оптимизацией памяти. В результате у него было 300 операций ввода-вывода в секунду в соответствии с соотношением 3 операций ввода-вывода в секунду / ГБ в Azure.
Предположительно "переменный" IOPS на сервере Basic оказался значительно больше, чем 300 IOPS, которые имел сервер с оптимизацией памяти.
Извлеченный урок: чтобы получить быстрый доступ к хранилищу в базе данных Azure, вам необходимо выделить достаточный объем хранилища для вашего сервера (даже если вам не нужно столько хранилища!).
Предложение для вашей группы параметров AWS при ЗАГРУЗКЕ миллионов строк данных,
innodb_change_buffer_max_size=50 # from 25 for improved LOAD speed during high volume process
когда закончите, вернитесь к 25% (или меньше) в зависимости от ваших потребностей в типичной работе.
На вашем экземпляре с улучшенной памятью
innodb_lru_scan_depth=100 # from 1024 to conserve 90% of CPU cycles used for function
Для следующего теста они должны сократить затраченное время.