Доклад Алексея Копытова рассматривает изменения производительности MySQL за последние два года, включая новшества в версиях 5.7 и GA. В нём обсуждаются оптимизации для read-only и read-write нагрузок, а также альтернативные движки хранения, такие как MyRocks и TokuDB. Отмечены проблемы с однопоточной производительностью и поддержка NUMA, а также намеченные улучшения в будущих версиях MySQL.

1. Производительность 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

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