Stato attuale di MySQL 5.7
MySQL 5.7 non è ideale in termini di scalabilità. La seguente figura illustra la relazione tra attraversamento TPC-C e concorrenza in MySQL 5.7.39 sotto una configurazione specifica. Questo include impostare il livello di isolamento delle transazioni a Read Committed e regolare il parametro innodb_spin_wait_delay per mitigare la degradazione della throughput.
Figura 1: Problemi di scalabilità in MySQL 5.7.39 durante le prove BenchmarkSQL
Dalla figura emerge chiaramente che i problemi di scalabilità limitano significativamente l’aumento della throughput di MySQL. Per esempio, dopo 100 concorrenze, la throughput inizia a declinare.
Per affrontare il precedente collasso del rendimento, è stato impiegato il pool di thread di Percona. La seguente figura illustra la relazione tra attraversamento TPC-C e concorrenza dopo aver configurato il pool di thread di Percona.
Figura 2: Il pool di thread di Percona mitiga i problemi di scalabilità in MySQL 5.7.39
Anche se il pool di thread introduce un overhead e il rendimento massimo è diminuito, ha mitigato il problema del collasso del rendimento sotto alta concorrenza.
Stato attuale di MySQL 8.0
Ora guardiamo ai progressi fatti da MySQL 8.0 riguardo alla scalabilità.
Ottimizzazione del Log Redo
Il primo miglioramento significativo è l’ottimizzazione del log 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]>.È stato condotto un test che confronta l’attraversamento TPC-C con differenti livelli di concorrenza prima e dopo l’ottimizzazione. I dettagli specifici sono mostrati nella seguente figura:
Figura 3: Impatto dell’ottimizzazione del log di ripetizione a differenti livelli di concorrenza
I risultati mostrati nella figura dimostrano una significativa incremento della throughput ai bassi livelli di concorrenza.
Ottimizzazione di Lock-Sys tramite sharding delle latche
La seconda migliorazione principale riguarda l’ottimizzazione di 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:23836Basandosi sul programma prima e dopo l’ottimizzazione con Lock-Sys, utilizzando BenchmarkSQL per confrontare la throughput TPC-C a differenti livelli di concorrenza, i risultati specifici sono mostrati nella seguente figura:
Figura 4: Impatto dell’ottimizzazione di Lock-Sys a differenti livelli di concorrenza
Dalla figura si può notare che l’ottimizzazione di Lock-Sys incrementa significativamente la throughput sotto condizioni di alta concorrenza, mentre l’effetto è meno pronunciato sotto bassa concorrenza a causa di meno conflitti.
Sharding delle latche per trx-sys
La terza migliorazione principale riguarda il sharding delle latche per 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]Basandosi su queste ottimizzazioni prima e dopo, utilizzando BenchmarkSQL per confrontare la throughput TPC-C a differenti livelli di concorrenza, i risultati specifici sono mostrati nella seguente figura:
Figura 5: Impatto del sharding delle latche in trx-sys a differenti livelli di concorrenza
Dalla figura si può notare che questa miglioria incrementa significativamente la throughput TPC-C, raggiungendo il suo massimo a 200 concorrenze. Da segnalare che l’impatto diminuisce a 300 concorrenze, principalmente a causa di problemi di scalabilità in corso nel sottosistema trx-sys Collegamenti a MVCC ReadView.
Riaffinamento di MySQL 8.0
Le altre migliorie sono le nostre estensioni indipendenti.
Miglioramenti alla struttura MVCC ReadView
Il primo miglioramento significativo è l’integrazione della struttura MVCC ReadView dati [1].
Sono stati condotti test di performance per valutare l’efficacia dell’ottimizzazione della MVCC ReadView. La figura seguente mostra una comparazione del throughput TPC-C a diversi livelli di concorrenza, prima e dopo la modifica della struttura dati MVCC ReadView.
Figura 6: Comparazione di prestazioni prima e dopo l’adozione della nuova struttura dati ibrida in NUMA
Dalla figura emerge chiaramente che questa trasformazione ha principalmente ottimizzato la scalabilità e migliorato il throughput massimo di MySQL in ambienti NUMA.
Evitare i problemi del doppio blocco
Il secondo miglioramento significativo è la risoluzione del problema del doppio blocco, in cui “doppio blocco” si riferisce alla necessità del blocco globale trx-sys richiesto da entrambi view_open e view_close [1].
Uso della versione MVCC ReadView ottimizzata, confrontare il throughput TPC-C prima e dopo le modifiche. I dettagli sono mostrati nella figura seguente:
Figura 7: Miglioramento delle prestazioni dopo aver eliminato il bottone della doppia chiusura
Dalla figura emerge chiaramente che le modifiche hanno significativamente migliorato la scalabilità in condizioni di alta concorrenza.
Meccanismo di limitazione delle transazioni
L’ultimo miglioramento è l’implementazione di un meccanismo di limitazione delle transazioni per proteggere contro la collasso delle prestazioni sotto concorrenza estrema [1] [2] [4].
La figura seguente raffigura la prova di carico sulla scalabilità TPC-C condotta dopo aver implementato la limitazione delle transazioni. La prova è stata eseguita in un scenario con il NUMA BIOS disabilitato, limitando l’accesso di fino a 512 thread utente nel sistema di transazioni.
Figura 8: Massima attraversamento TPC-C in BenchmarkSQL con i meccanismi di limitazione delle transazioni
Dalla figura è chiaro che l’implementazione di meccanismi di limitazione delle transazioni consente di migliorare significativamente la scalabilità di MySQL.
Riepilogo
In generale, è del tutto possibile per MySQL mantenere la performance senza collasso a decine di migliaia di connessioni concorrenti in scenari a basso conflitto del testing TPC-C di BenchmarkSQL.
Riferimenti
- Bin Wang (2024). The Art of Problem-Solving in Software Engineering: How to Make MySQL Better.
- The New MySQL Thread Pool
- Paweł Olchawa. 2018. MySQL 8.0: New Lock free, scalable WAL design. MySQL Blog Archive.
- Xiangyao Yu. An evaluation of concurrency control with one thousand cores. PhD thesis, Massachusetts Institute of Technology, 2015.
- MySQL 8.0 Reference Manual
Source:
https://dzone.com/articles/mysql-scalability-improvement-for-benchmarksql