Производительность MySQL:что нового?

Алексей Копытов

Производительность MySQL: что нового?

Алексей Копытов

О чём доклад?

обзор изменений производительности за ~2 годаальтернативы InnoDB (MyRocks, TokuDB)текущие проблемы

MySQL 5.7!

GA версия выпущена 19 октября 2015г.качественный релизогромное количество новый функций и улучшений производительностиобзорный доклад по всем новым возможностям от Дмитрия Ленёва сегодня

Скорость соединения

создание нового соединения стало быстрееособенно когда много клиентовsysbench connect:

Производительность на read-only нагрузках

sysbench OLTP POINT_SELECT , 72 ядра (4x18-ядерных Intel Xeon E7-58800 v3):

работа по оптимизации началась ещё в 5.6дальнейшие улучшения масштабируемости в 5.7:

1.6 миллиона key/value запросов в секунду1.8 миллиона, если использовать prepared statements

нет записи в базу (не назначается и не записывается TRX_ID )оптимизации в MDL коде для DML запросов засчёт более дорогих DDL блокировокустранение THR_LOCK блокировок для InnoDB таблиц

Производительность на read-only нагрузках

Read-only транзакции больше не нужно явно помечать:

в MySQL 5.6 требуется явное указание не-AUTOCOMMIT транзакций

START TRANSACTION READ ONLYSELECT ...;SELECT ...;COMMIT;

SQL

в MySQL 5.7 транзакции считаются read-only по умолчанию.

START TRANSACTION;SELECT ...;SELECT ...;COMMIT;

SQL

Производительность на read-only нагрузках

sysbench OLTP RO, 72 ядра (4x18-ядерных Intel Xeon E7-58800 v3):

1M запросов (~70K OLTP_RO транзакций) в секунду

Производительность на read-only нагрузках

Обычный Adaptive Hash Index:

Cекционированный Adaptive Hash Index

использует хэш для поиска по "популярным" значениям B-Tree ключейхэш при частых обновлениях становится узким местомобновления возможны даже при read-only нагрузке!

секционируем по index_idреализовано в XtraDB (<= 2009г.)аналогичная опция в MySQL 5.7 ( innodb_adaptive_hash_index_parts [=8])

Производительность на read-only нагрузках

Оставшиеся проблемы с масштабируемостью:

Adaptive Hash Index

блокировки страниц в buffer pool (block lock)

bug #74954 "Inefficient InnoDB row stats implementation" и bug #79455 "Restoreget_sched_indexer_t in 5.7"

на IO-bound read-only нагрузках: fil_system->mutex

секционирование по index_id – не самый лучший вариантобещают полностью переписать в MySQL 8

мьютексы были переписаны в 5.7rwlock-и плохо масштабируются, обещают переписать в MySQL 8

cчётчики считанных/изменённых записей плохо масштабируются намногоядерных архитектурах

Производительность на read-write нагрузках

убрали index lock:

меньше блокировок на log_sys->mutex

сброс страниц на диск (flushing)

блокировка на весь индекс, когда нужно изменить структуру деревав 5.7 блокировка только при конфликтующих изменениях

в основном для innodb_flush_log_at_trx_commit=2

несколько параллельных потоков ( innodb_page_cleaners=4 )оптимизации в адаптивном алгоритме

Производительность на read-write нагрузках

Временные InnoDB таблицы в 5.7:

используются вместо MyISAM по умолчанию оптимизатором для внутреннихтаблицне генерируют записей в транзакционный журналотдельное табличное пространство ibtmp1 – пересоздаётся при старте"ослабленный" MVCCне используют doublewrite bufferбыстрее MyISAM в большинстве случаев

Производительность на read-write нагрузках

Проблемы:

проблемы с масштабируемостью из-за неуспеващего флашингаdoublewrite в качестве «узкого места»innodb_log_write_ahead_size увеличивает write amplification приinnodb_flush_log_at_trx_commit=1

Производительность на read-write нагрузках

Percona Server:

отдельные потоки для LRU flushingпараллельный doublewrite buffer:

Производительность на read-write нагрузках

много улучшенийно есть куда стремитьсяработа кипит :)

Новые системные переменные

innodb_buffer_pool_size теперь динамическая переменнаяinnodb_buffer_pool_dump_pct=25innodb_fill_factor=100 (для sorted index build)innodb_log_write_ahead_size=8192innodb_numa_interleave=offinnodb_page_cleaners=1

Изменения в значениях по умолчанию

Системные переменные с новыми значениями по умолчанию в 5.7:

binlog_format=rowsync_binlog=1ssl=1innodb_buffer_pool_dump_at_shutdown=on иinnodb_buffer_pool_load_at_startup=oninnodb_checksum_algorithm=crc32innodb_log_buffer_size=16Minnodb_purge_threads=4table_open_cache_instances=16

MyRocks и TokuDB

MyRocks

движок хранения от Facebook на основе RocksDB (форк LevelDB от Google)LSM-деревья, оптимизирован на запись9 миллиардов запросов/сек в Facebookнизкий write amplification (SSD!)высокая компрессия (SSD!)

MyRocks

Источник: Mark Callaghan, MyRocks, MongoRocks & RocksDB

MyRocks

Источник: Mark Callaghan, MyRocks, MongoRocks & RocksDB

Ограничения MyRocks

нет поддержки многих возможностей InnoDB

только бинарные правила сортировки (collations)нет в MariaDB/Perconaстабильность уровня "можно пробовать"

секционированиеonline DDLtransportable tablespacesвнешние ключигеометрические/полнотекстовые индексывиртуальные колонки

TokuDB

разработка с 2007г."фрактальные" деревьяна самом деле B-Tree с расширениямиразрабатывается в Percona с 2015г.

TokuDB

Фрактальные деревья:

накапливание отложенных изменений в корневых узлах индексов ипроталкиваниек листьям по мере заполнения

TokuDB

Сильные стороны:

быстрее InnoDB при большом количестве индексовнесколько кластеризованных индексовинтенсивные нагрузки на запись, когда dataset > RAMэкономия места на диске за счёт продвинутой компрессии (SSD!)read-free репликация

Ограничения TokuDBНет поддержки многих возможностей InnoDB:

проблема с чекпойнтами и стабильностью времени отклика (источник: percona.com/blog)

секционированиеonline DDLtransportable tablespacesвнешние ключигеометрические/полнотекстовые индексывиртуальные колонки

уникальные индексы – медленноSELECT -ы дорогиенизкие темпы разработки

Текущие проблемы и будущие версииMySQL

Однопоточная производительность

каждый мажорный релиз MySQL на ~5% медленее предыдущего (нолучшемасштабируется)серия публикаций от Mark Callaghan и Петра Зайцева

Однопоточная производительность

Почему это важно:

производительность в 1 соединение == время откликапараллельность репликации ограниченаадминистративные задачи – как правило один потокв большинстве случаев сервер работает с небольшим количеством соединений

Однопоточная производительность

Почему это сложно:

от версии к версии кода большебольше ветвелений, кэш-промахов и т. д.дробление блокировок ведёт к лучше масштабируемости, но болеемедленнойоднопоточной работенет "низковисящих фруктов"

Однопоточная производительность

Почему это до сих пор проблема:

MariaDB работали в этом направлении, но о результатах ничего неизвестно

не приоритет для разработчиковнужно помочь приоритизироватьне стесняйтесь сообщать на http://bugs.mysql.com/, если для вас это тоже проблема

Умная поддержка NUMA

Предыстория вопроса:

Twitter/Percona/MariaDB, 2012:

Jeremy Cole, 2010:The MySQL “swap insanity” problem and the effects of the NUMA architectureсбросить FS cacheвключить чередование страницобеспечить инициализацию страниц памяти при старта, а не в процессеработы

чередование страниц buffer pool + равномерное распределение между нодамиnuma_interleaveinnodb_buffer_pool_populateflush_caches

Умная поддержка NUMA

Oracle MySQL, 2015:

innodb_numa_interleave – только частичное решение проблемыопция flush_caches оставлена в Percona Server 5.7

Умная поддержка NUMA

проблема с NUMA не только в излишнем использовании swap.NUMA cache line contention:

многие структуры данных не используют чередование:bug #79358: No NUMA interleaving for some shared structures

"горячие" структуры данных в основном в одной NUMA нодеблокировки вызывают значительный трафик между нодами

внутренний словарь данных в InnoDBкэш табличных пространствбуфер транзакционного журналаи т.д.

Умный параллельный purge

purge не справляется на нагрузках с очень интенсивной записьюнесколько purge потоков соревнуются за один и тот же индекснужно более "интеллектуальное" распределение задач между потокамиhttps://bugs.mysql.com/81368экспериментальный патч в Percona ~ 2013г.скорее всего полный редизайн в MySQL 8

Спасибо! Вопросы?