Как может быть улучшена сcalability of MySQL для BenchmarkSQL TPC-C Testing?

Текущее состояние MySQL 5.7

MySQL 5.7 не идеальна с точки зрения масштабируемости. Следующая диаграмма иллюстрирует взаимосвязь между пропускной способностью TPC-C и конкуррентностью в MySQL 5.7.39 с конкретной конфигурацией. Это включает установку уровня изоляции транзакции на “Read Committed” и настройку параметра innodb_spin_wait_delay для снижения деградации пропускной способности.

Рисунок 1: Проблемы масштабируемости в MySQL 5.7.39 во время тестирования BenchmarkSQL

Из диаграммы ясно, что проблемы масштабируемости значительно ограничивают увеличение пропускной способности MySQL. Например, после 100 уровня конкуррентности пропускная способность начинает снижаться. 

Чтобы решить упомянутую проблему с обвалом производительности, был использован пул потоков Percona. Следующая диаграмма иллюстрирует взаимосвязь между пропускной способностью TPC-C и конкуррентностью после настройки пула потоков Percona.

Рисунок 2: Пул потоков Percona смягчает проблемы масштабируемости в MySQL 5.7.39

Хотя пул потоков добавляет некоторые накладные расходы и снижает максимальную производительность, он смягчает проблему обвала производительности при высокой конкуррентности.

Текущее состояние MySQL 8.0

Рассмотрим усилия MySQL 8.0 по повышению масштабируемости.

Оптимизация журнала Redo

Первым серьезным улучшением стала оптимизация журнала Redo [3].

commit 6be2fa0bdbbadc52cc8478b52b69db02b0eaff40
Author: Paweł Olchawa <[email protected]>
Date:   Wed Feb 14 09:33:42 2018 +0100
    
    WL#10310 Redo log optimization: dedicated threads and concurrent log buffer.

    0. Log buffer became a ring buffer, data inside is no longer shifted.
    1. User threads are able to write concurrently to log buffer. 
    2. Relaxed order of dirty pages in flush lists - no need to synchronize
       the order in which dirty pages are added to flush lists.
    3. Concurrent MTR commits can interleave on different stages of commits.
    4. Introduced dedicated log threads which keep writing log buffer: 
        * log_writer: writes log buffer to system buffers,
        * log_flusher: flushes system buffers to disk.
       As soon as they finished writing (flushing) and there is new data to 
       write (flush), they start next write (flush).
    5. User threads no longer write / flush log buffer to disk, they only
       wait by spinning or on event for notification. They do not have to 
       compete for the responsibility of writing / flushing.
    6. Introduced a ring buffer of events (one per log-block) which are used
       by user threads to wait for written/flushed redo log to avoid:
        * contention on single event
        * false wake-ups of all waiting threads whenever some write/flush
          has finished (we can wake-up only those waiting in related blocks)
    7. Introduced dedicated notifier threads not to delay next writes/fsyncs:
        * log_write_notifier: notifies user threads about written redo,
        * log_flush_notifier: notifies user threads about flushed redo.
    8. Master thread no longer has to flush log buffer.
    ...
    30. Mysql test runner received a new feature (thanks to Marcin):
        --exec_in_background.
    Review: RB#15134
    Reviewers:
        - Marcin Babij <[email protected]>,
        - Debarun Banerjee <[email protected]>.
    Performance tests:
        - Dimitri Kravtchuk <[email protected]>,
        - Daniel Blanchard <[email protected]>,
        - Amrendra Kumar <[email protected]>.
    QA and MTR tests:
        - Vinay Fisrekar <[email protected]>.

Был проведен тест сравнения пропускной способности TPC-C с различными уровнями конкуррентности до и после оптимизации. Специфические детали представлены на следующем рисунке:

Рисунок 3: Влияние оптимизации журнала повторных операций на различных уровнях конкурентности

Результаты, показанные на рисунке, свидетельствуют о значительном улучшении производительности при низких уровнях конкурентности.

Оптимизация Lock-Sys через 分割 латча

Второе значительное улучшение — это оптимизация Lock-Sys [5].

commit 1d259b87a63defa814e19a7534380cb43ee23c48
Author: Jakub Łopuszański <[email protected]>
Date:   Wed Feb 5 14:12:22 2020 +0100
    
    WL#10314 - InnoDB: Lock-sys optimization: sharded lock_sys mutex

    The Lock-sys orchestrates access to tables and rows. Each table, and each row,
    can be thought of as a resource, and a transaction may request access right for
    a resource. As two transactions operating on a single resource can lead to
    problems if the two operations conflict with each other, Lock-sys remembers
    lists of already GRANTED lock requests and checks new requests for conflicts in
    which case they have to start WAITING for their turn.
    
    Lock-sys stores both GRANTED and WAITING lock requests in lists known as queues.
    To allow concurrent operations on these queues, we need a mechanism to latch
    these queues in safe and quick fashion.
    
    In the past a single latch protected access to all of these queues.
    This scaled poorly, and the managment of queues become a bottleneck.
    In this WL, we introduce a more granular approach to latching.
    
    Reviewed-by: Pawel Olchawa <[email protected]>
    Reviewed-by: Debarun Banerjee <[email protected]>
      RB:23836

Программа до и после оптимизации Lock-Sys, используя BenchmarkSQL для сравнения производительности TPC-C с учетом конкурентности, дает следующий результат:

Рисунок 4: Влияние оптимизации Lock-Sys на различных уровнях конкурентности

Согласно рисунку, оптимизация Lock-Sys значительно улучшает производительность при высоких уровнях конкурентности, в то время как ее эффект менее заметный при низких уровнях конкурентности в связи с меньшим числом конфликтов.

分 割 латча для trx-sys

Третье значительное улучшение — это分割 латча для trx-sys.

commit bc95476c0156070fd5cedcfd354fa68ce3c95bdb
Author: Paweł Olchawa <[email protected]>
Date:   Tue May 25 18:12:20 2021 +0200
    
    BUG#32832196 SINGLE RW_TRX_SET LEADS TO CONTENTION ON TRX_SYS MUTEX
    
    1. Introduced shards, each with rw_trx_set and dedicated mutex.
    2. Extracted modifications to rw_trx_set outside its original critical sections
       (removal had to be extracted outside trx_erase_lists).
    3. Eliminated allocation on heap inside TrxUndoRsegs.
    4. [BUG-FIX] The trx->state and trx->start_time became converted to std::atomic<>
       fields to avoid risk of torn reads on egzotic platforms.
    5. Added assertions which ensure that thread operating on transaction has rights
       to do so (to show there is no possible race condition).
    
    RB: 26314
    Reviewed-by: Jakub Łopuszański [email protected]

Сравнивая производительность TPC-C с учетом конкурентности до и после этих оптимизаций, с помощью BenchmarkSQL, получены следующие результаты:

Рисунок 5: Влияние分割 латча в trx-sys на различных уровнях конкурентности

Согласно рисунку, эта улучшенность значительно повышает производительность TPC-C, достигая своего пика при 200 уровне конкурентности. Следует отметить, что эффект уменьшается до 300 уровня конкурентности, что связано principalmente с проблемами масштабирования subsystem trx-sys, связанных с MVCC ReadView.

Развитие MySQL 8.0

Остальные улучшения — это наши независимые усовершенствования.

Улучшения MVCC ReadView

Первоначальным крупным улучшением является улучшение данной структуры данных MVCC ReadView [1].

Для оценки эффективности оптимизации MVCC ReadView были проведены тесты по сравнению производительности. Diagramма ниже показывает сравнение производительности TPC-C с различными уровнями конкурентности, до и после изменения структуры данных MVCC ReadView.

Рисунок 6: Сравнение производительности до и после принятия новой гибкой структуры данных в NUMA

Согласно рисунку, эта трансформация, прежде всего, оптимизировала масштабность и улучшила максимальную производительность MySQL в среде NUMA.

Предотвращение проблем с двойным захватом замков

Второе важное улучшение, сделанное нами, связано с решением проблемы двойного захвата замков, где “двойной захват замков” означает требует глобального ограничения trx-sys замками, используемых обоими view_open и view_close [1].

Используя оптимизированную версию MVCC ReadView, сравните производительность TPC-C до и после изменений. подробности показывает следующий рисунок:

Рисунок 7: Улучшение производительности после устранения барьера двойного захвата замков

Согласно рисунку, изменения显著но улучшили масштабность в условиях высокой конкурентности.

Механизм ограничения транзакций

Последним улучшением является внедрение механизма ограничения транзакций для защиты от краху производительности под очень высокой конкурентностью [1] [2] [4].

На следующем рисунке изображен стресс-тест по нагрузке на масштабность TPC-C, проведенный после внедрения механизма ограничения транзакций. Тест был выполнен в сценарии с отключенным NUMA BIOS, ограничивая доступность до 512 пользовательских потоков в систему транзакций.

Рисунок 8: Максимальная производительность TPC-C в BenchmarkSQL с использованием механизмов ограничения транзакций

Из рисунка ясно, что внедрение механизмов ограничения транзакций значительно улучшает масштабность MySQL.

Резюме

В целом, для MySQL полностью реализуемо, чтобы поддерживать высокую производительность без обвалов в сценариях BenchmarkSQL TPC-C с десятками тысяч соединений потоков в низкоконфликтных ситуациях.

Примечания

1. Вань Бин (2024). Искусство решения проблем в области программной инженерии: Как улучшить MySQL.
2. Новый пул потоков MySQL
3. Павел Ольчава. 2018. MySQL 8.0: Новая бесблокирующая, масштабируемая архитектура WAL. Архив блогов MySQL.
4. Юань Яо. Оценка конкурентного контроля с тысячей ядер. Диссертация на соискание ученой степени доктора наук, Massachusetts Institute of Technology, 2015.
5. Руководство по MySQL 8.0