"Производительность MySQL: что нового?"
2 likes15,844 views
Доклад Алексея Копытова рассматривает изменения производительности MySQL за последние два года, включая новшества в версиях 5.7 и GA. В нём обсуждаются оптимизации для read-only и read-write нагрузок, а также альтернативные движки хранения, такие как MyRocks и TokuDB. Отмечены проблемы с однопоточной производительностью и поддержка NUMA, а также намеченные улучшения в будущих версиях MySQL.
![Производительность на 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])](https://image.slidesharecdn.com/random-160718124443/85/MySQL-9-320.jpg)
"Производительность MySQL: что нового?"
- 2. Производительность MySQL: что нового? Алексей Копытов
- 3. О чём доклад? обзор изменений производительности за ~2 года альтернативы InnoDB (MyRocks, TokuDB) текущие проблемы
- 4. MySQL 5.7! GA версия выпущена 19 октября 2015г. качественный релиз огромное количество новый функций и улучшений производительности обзорный доклад по всем новым возможностям от Дмитрия Ленёва сегодня
- 5. Скорость соединения создание нового соединения стало быстрее особенно когда много клиентов sysbench connect:
- 6. Производительность на 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 таблиц
- 7. Производительность на read-only нагрузках Read-only транзакции больше не нужно явно помечать: в MySQL 5.6 требуется явное указание не-AUTOCOMMIT транзакций START TRANSACTION READ ONLY SELECT ...; SELECT ...; COMMIT; SQL в MySQL 5.7 транзакции считаются read-only по умолчанию. START TRANSACTION; SELECT ...; SELECT ...; COMMIT; SQL
- 8. Производительность на read-only нагрузках sysbench OLTP RO, 72 ядра (4x18-ядерных Intel Xeon E7-58800 v3): 1M запросов (~70K OLTP_RO транзакций) в секунду
- 9. Производительность на 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])
- 10. Производительность на read-only нагрузках Оставшиеся проблемы с масштабируемостью: Adaptive Hash Index блокировки страниц в buffer pool (block lock) bug #74954 "Inefficient InnoDB row stats implementation" и bug #79455 "Restore get_sched_indexer_t in 5.7" на IO-bound read-only нагрузках: fil_system->mutex секционирование по index_id – не самый лучший вариант обещают полностью переписать в MySQL 8 мьютексы были переписаны в 5.7 rwlock-и плохо масштабируются, обещают переписать в MySQL 8 cчётчики считанных/изменённых записей плохо масштабируются на многоядерных архитектурах
- 11. Производительность на read-write нагрузках убрали index lock: меньше блокировок на log_sys->mutex сброс страниц на диск (flushing) блокировка на весь индекс, когда нужно изменить структуру дерева в 5.7 блокировка только при конфликтующих изменениях в основном для innodb_flush_log_at_trx_commit=2 несколько параллельных потоков ( innodb_page_cleaners=4 ) оптимизации в адаптивном алгоритме
- 12. Производительность на read-write нагрузках Временные InnoDB таблицы в 5.7: используются вместо MyISAM по умолчанию оптимизатором для внутренних таблиц не генерируют записей в транзакционный журнал отдельное табличное пространство ibtmp1 – пересоздаётся при старте "ослабленный" MVCC не используют doublewrite buffer быстрее MyISAM в большинстве случаев
- 13. Производительность на read-write нагрузках Проблемы: проблемы с масштабируемостью из-за неуспеващего флашинга doublewrite в качестве «узкого места» innodb_log_write_ahead_size увеличивает write amplification при innodb_flush_log_at_trx_commit=1
- 14. Производительность на read-write нагрузках Percona Server: отдельные потоки для LRU flushing параллельный doublewrite buffer:
- 15. Производительность на read-write нагрузках много улучшений но есть куда стремиться работа кипит :)
- 16. Новые системные переменные innodb_buffer_pool_size теперь динамическая переменная innodb_buffer_pool_dump_pct=25 innodb_fill_factor=100 (для sorted index build) innodb_log_write_ahead_size=8192 innodb_numa_interleave=off innodb_page_cleaners=1
- 17. Изменения в значениях по умолчанию Системные переменные с новыми значениями по умолчанию в 5.7: binlog_format=row sync_binlog=1 ssl=1 innodb_buffer_pool_dump_at_shutdown=on и innodb_buffer_pool_load_at_startup=on innodb_checksum_algorithm=crc32 innodb_log_buffer_size=16M innodb_purge_threads=4 table_open_cache_instances=16
- 18. MyRocks и TokuDB
- 19. MyRocks движок хранения от Facebook на основе RocksDB (форк LevelDB от Google) LSM-деревья, оптимизирован на запись 9 миллиардов запросов/сек в Facebook низкий write amplification (SSD!) высокая компрессия (SSD!)
- 20. MyRocks Источник: Mark Callaghan, MyRocks, MongoRocks & RocksDB
- 21. MyRocks Источник: Mark Callaghan, MyRocks, MongoRocks & RocksDB
- 22. Ограничения MyRocks нет поддержки многих возможностей InnoDB только бинарные правила сортировки (collations) нет в MariaDB/Percona стабильность уровня "можно пробовать" секционирование online DDL transportable tablespaces внешние ключи геометрические/полнотекстовые индексы виртуальные колонки
- 23. TokuDB разработка с 2007г. "фрактальные" деревья на самом деле B-Tree с расширениями разрабатывается в Percona с 2015г.
- 24. TokuDB Фрактальные деревья: накапливание отложенных изменений в корневых узлах индексов ипроталкивание к листьям по мере заполнения
- 25. TokuDB Сильные стороны: быстрее InnoDB при большом количестве индексов несколько кластеризованных индексов интенсивные нагрузки на запись, когда dataset > RAM экономия места на диске за счёт продвинутой компрессии (SSD!) read-free репликация
- 26. Ограничения TokuDB Нет поддержки многих возможностей InnoDB: проблема с чекпойнтами и стабильностью времени отклика (источник: percona.com/blog) секционирование online DDL transportable tablespaces внешние ключи геометрические/полнотекстовые индексы виртуальные колонки уникальные индексы – медленно SELECT -ы дорогие низкие темпы разработки
- 27. Текущие проблемы и будущие версии MySQL
- 28. Однопоточная производительность каждый мажорный релиз MySQL на ~5% медленее предыдущего (но лучшемасштабируется) серия публикаций от Mark Callaghan и Петра Зайцева
- 29. Однопоточная производительность Почему это важно: производительность в 1 соединение == время отклика параллельность репликации ограничена административные задачи – как правило один поток в большинстве случаев сервер работает с небольшим количеством соединений
- 30. Однопоточная производительность Почему это сложно: от версии к версии кода больше больше ветвелений, кэш-промахов и т. д. дробление блокировок ведёт к лучше масштабируемости, но болеемедленной однопоточной работе нет "низковисящих фруктов"
- 31. Однопоточная производительность Почему это до сих пор проблема: MariaDB работали в этом направлении, но о результатах ничего неизвестно не приоритет для разработчиков нужно помочь приоритизировать не стесняйтесь сообщать на http://bugs.mysql.com/, если для вас это тоже проблема
- 32. Умная поддержка 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_interleave innodb_buffer_pool_populate flush_caches
- 33. Умная поддержка NUMA Oracle MySQL, 2015: innodb_numa_interleave – только частичное решение проблемы опция flush_caches оставлена в Percona Server 5.7
- 34. Умная поддержка NUMA проблема с NUMA не только в излишнем использовании swap. NUMA cache line contention: многие структуры данных не используют чередование: bug #79358: No NUMA interleaving for some shared structures "горячие" структуры данных в основном в одной NUMA ноде блокировки вызывают значительный трафик между нодами внутренний словарь данных в InnoDB кэш табличных пространств буфер транзакционного журнала и т.д.
- 35. Умный параллельный purge purge не справляется на нагрузках с очень интенсивной записью несколько purge потоков соревнуются за один и тот же индекс нужно более "интеллектуальное" распределение задач между потоками https://bugs.mysql.com/81368 экспериментальный патч в Percona ~ 2013г. скорее всего полный редизайн в MySQL 8