"Производительность mysql: что нового?"
TRANSCRIPT
Производительность 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
Спасибо! Вопросы?