كيف يمكن تحسين قابلية توسيع MySQL لاختبار TPC-C BenchmarkSQL؟

وضع الورقة الحالي لـ MySQL 5.7

إن MySQL 5.7 ليس مثالياً من حيث التنمية القائمة على القدرة. يوضح الرسم البياني التالي علاقة معدل إنتاجية TPC-C والتنافر المتعدد المستخدمين في MySQL 5.7.39 وفقاً للإعدادات المحددة. يشمل هذا الرسم البياني تعيين مستوى التجاوز الحالي للتجار المعمولي وتغيير ما يسمى بماركتر 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 المتعلقة بالتنمية القائمة على القدرة.

تحسين تنظيم سجل التجديد

أول تحسين هو تنظيم سجل التجديد [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]>.

تم قيام باختبار

الشكل 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]

بناءً على هذه التحسينات قبل وبعد، باستخدام BenchmarkSQL لمقارنة إنتاجية TPC-C مع التواقت، النتائج المحددة موضحة في الشكل التالي:

الشكل 5: تأثير تقسيم المزلاج في trx-sys تحت مستويات تواقت مختلفة

من الشكل، يمكن ملاحظة أن هذا التحسين يزيد بشكل كبير من إنتاجية TPC-C، ويصل إلى ذروته عند تواقت 200. من الجدير بالذكر أن التأثير يتضاءل عند تواقت 300، ويرجع ذلك بشكل أساسي إلى مشاكل التوسع المستمرة في نظام trx-sys المتعلقة بـ MVCC ReadView.

تحسين MySQL 8.0

التحسينات المتبقية هي تحسيناتنا المستقلة.

تحسينات لـ MVCC ReadView

التحسين الأولي هو تحسين بنية المعلومات لـ MVCC ReadView [1].

وقد أجريت بعض التجارب المقارنة لتقييم فعالية تحسين بنية MVCC ReadView. يظهر في الرسم البياني أدناه مقارنة مع معدلات TPC-C مع مستويات متناولية مختلفة، قبل وبعد تعديل بنية MVCC ReadView التحسينية.

رسم البياني 6: مقارنة الأداء قبل وبعد اتخاذ تنظيم البيانات المزدوج الجديد في NUMA

من خلال الرسم البياني، يبرز أن هذه التحولات قامت بتحسين القابلية للتنمية وحسن معدلات التنقل الأعلى لـ MySQL في بيئات NUMA.

تجنب مشاكل القفل المزدوج

التحسين الثاني الرئيسي الذي قمنا به هو تعاليم مشاكل القفل المزدوج، حيث “القفل المزدوج” يشمل إحتياج لقفل النظام العام للتراكيب العاملية من قبل view_open و view_close [1].

باستخدام النسخة المحسنة لـ MVCC ReadView، قارن معدلات TPC-C قبل وبعد التغييرات. تفاصيل توضحت في الرسم البياني التالي:

رسم البياني 7: تحسين الأداء بعد تخليال قنبلة القفل المزدوج

من خلال الرسم البياني، يبرز أن التغييرات قامت بتحسين القابلية للتنمية بشكل كبير تحت شروط متعددة التناول.

آلية قيود التعاملات

التحسين الأخير هو تنفيذ آلية قيود التعاملات للحماية ضد هندم الأداء في بيئات متعددة التناول للغ

التالي تصور الاختبار الضغط لتوسعية TPC-C الذي تم إجراؤه بعد تطبيق تحكم في تدفق المعاملات. قامت الاختبار بتجربة سيناريو مع تعطيل BIOS NUMA، وتحديد الدخول لحد 512 خيط مستخدم في نظام المعاملات.

الرسم البياني 8: السعة القصوى لـ TPC-C في BenchmarkSQL معآليات تحكم في تدفق المعاملات

من الرسم البياني يتضح بأن تطبيقآليات تحكم في تدفق المعاملات يحسن بشكل ملحوظ قابلية MySQL للتوسعة.

الملخص

في الواجهة العامة، من الممكن تماماً لـ MySQL أن تحافظ على الأداء دون تحطيم في عشرات الآلاف من الاتصالات المتزامنة في أوضاع منخفضة التصادم في اختبار TPC-C لـ BenchmarkSQL.

المراجع

1. بين وانغ (2024). فن الحلول في مهندسة البرمجيات: كيف يمكن جعل MySQL أفضل.
2. المجمع الجديد لـ MySQL
3. باول أولتشافا. 2018. MySQL 8.0: تصميم جديد للسجل الحرر من القفل، قابل للتوسعة.أرشيف مدونة MySQL
4. سيانغياو يو. تقييم السيطرة في التزامن مع ألف نوع. ماجستير العلوم، معهد ماساتشوستس للتقنية، 2015.
5. دليل MySQL 8.0 للمرجع