مشاركة عبر

تشخيص استكشاف الأخطاء وإصلاحها لأداء SQL Hyperscale

  • مقالة

ينطبق على: قاعدة بيانات Azure SQL

لاستكشاف مشكلات الأداء في قاعدة بيانات Hyperscale وإصلاحها، فإن منهجيات ضبط الأداء العامة في عقدة حساب Azure SQL Database هي نقطة البداية لتحقيق الأداء. ومع ذلك، نظراً لـ البنية الموزعة لـ Hyperscale، فقد تمت إضافة تشخيصات إضافية للمساعدة. توضح هذه المقالة بيانات التشخيص الخاصة بـ Hyperscale.

سجل الاختناق ينتظر

يحتوي كل مستوى من مستويات خدمة Azure SQL Database على حدود لمعدل إنشاء السجلات يتم فرضها عبر إدارة معدل السجل. في Hyperscale، يتم تعيين حد إنشاء السجل حالياً على 100 ميغابايت/ثانية، بغض النظر عن مستوى الخدمة. ومع ذلك، هناك أوقات يجب فيها تقييد معدل إنشاء السجل في النسخة المتماثلة الأساسية للحساب للحفاظ على قابلية الاسترداد لاتفاقيات مستوى الخدمة. يحدث هذا التقييد عندما يكون خادم صفحة أو نسخة متماثلة أخرى للحساب متأخراً بشكل كبير عن تطبيق سجلات سجل جديدة من خدمة السجل.

تصف أنواع الانتظار التالية (في sys.dm_os_wait_stats) أسباب إمكانية تقييد معدل السجل في النسخة المتماثلة الأساسية للحساب:

نوع الانتظار الوصف
RBIO_RG_STORAGE يحدث عندما يتم اختناق معدل إنشاء سجل عقدة الحساب الأساسي لقاعدة بيانات Hyperscale بسبب استهلاك السجل المتأخر في خادم (خوادم) الصفحة.
RBIO_RG_DESTAGE يحدث عندما يتم اختناق معدل إنشاء سجل عقدة لحساب قاعدة بيانات Hyperscale نظراً لاستهلاك السجل المتأخر بواسطة تخزين السجل طويل المدى.
RBIO_RG_REPLICA يحدث عندما يتم اختناق معدل إنشاء سجل عقدة لحساب قاعدة بيانات Hyperscale نظراً لاستهلاك السجل المتأخر بواسطة النسخة (النسخ) المتماثلة الثانوية القابلة للقراءة.
RBIO_RG_GEOREPLICA يحدث عندما يتم اختناق معدل إنشاء سجل عقدة حساب قاعدة بيانات Hyperscale بسبب تأخر استهلاك السجل بواسطة النسخة المتماثلة Geo-Secondary.
RBIO_RG_LOCALDESTAGE يحدث عندما يتم اختناق معدل إنشاء سجل عقدة لحساب قاعدة بيانات Hyperscale بسبب تأخر استهلاك السجل بواسطة خدمة السجل.

يقرأ خادم الصفحة

لا تقم النسخ المتماثلة للحساب بالتخزين المؤقت لنسخة كاملة من قاعدة البيانات محلياً. يتم تخزين البيانات المحلية للنسخة المتماثلة المحسوبة في تجمع المخزن المؤقت (في الذاكرة) وفي ذاكرة التخزين المؤقت لملحق تجمع المخزن المؤقت المرن المحلي (RBPEX) وهي ذاكرة تخزين مؤقت جزئية (غير مغطاة) لصفحات البيانات. يتناسب حجم ذاكرة التخزين المؤقت المحلية RBPEX هذه مع حجم الحوسبة وهي ثلاثة أضعاف ذاكرة طبقة الحوسبة. يشبه RBPEX تجمع المخزن المؤقت من حيث إنه يحتوي على البيانات التي يتم الوصول إليها بشكل متكرر. من ناحية أخرى، يحتوي كل خادم صفحة على ذاكرة تخزين مؤقت RBPEX تغطي الجزء من قاعدة البيانات التي يحتفظ بها.

عند إصدار قراءة على نسخة متماثلة للحساب، إذا لم تكن البيانات موجودة في تجمع المخزن المؤقت أو ذاكرة التخزين المؤقت المحلية RBPEX، فسيتم إصدار استدعاء دالة getPage(pageId، LSN)، ويتم جلب الصفحة من خادم الصفحة المقابل. القراءات من خوادم الصفحة هي قراءات عن بعد، وبالتالي فهي أبطأ من القراءات من RBPEX المحلي. عند استكشاف مشكلات الأداء المتعلقة بالإدخال والإخراج وإصلاحها، نحتاج إلى أن نكون قادرين على معرفة عدد IO التي تم إجراؤها عبر قراءات أبطأ نسبياً لخادم الصفحات البعيد.

تحتوي العديد من طرق العرض الديناميكية المُدارة (DMVs) والأحداث الممتدة على أعمدة وحقول تحدد عدد عمليات القراءة عن بُعد من خادم الصفحة، والتي يمكن مقارنتها بإجمالي القراءات. يقوم مخزن الاستعلام أيضاً بالتقاط القراءات عن بُعد كجزء من إحصائيات وقت تشغيل الاستعلام.

  • تتوفر أعمدة لتقرير قراءات خادم الصفحة في تنفيذ DMVs وعروض الكتالوج، مثل:

  • تتم إضافة قراءات خادم الصفحة إلى الأحداث الممتدة التالية:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query-store_execution_runtime_info

  • تتم إضافة ActualPageServerReads/ActualPageServerReadAheads إلى خطة الاستعلام XML للخطط الفعلية. على سبيل المثال:

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

ملاحظة

لعرض هذه السمات في نافذة خصائص خطة الاستعلام، يلزم Management Studio 18.3 أو أحدث.

إحصائيات الملف الظاهري ومحاسبة IO

في Azure SQL Database، تعد sys.dm_io_virtual_file_stats() DMF هي الطريقة الأساسية لمراقبة إدخال بيانات SQL لقاعدة البيانات. تختلف خصائص IO في Hyperscale بسبب التصميم المعماري. في هذا القسم، نركز على IO (القراءة والكتابة) لملفات البيانات كما هو موضح في DMF هذا. في Hyperscale، يتوافق كل ملف بيانات مرئي في DMF مع خادم صفحة بعيد. ذاكرة التخزين المؤقت RBPEX المذكورة هنا هي ذاكرة تخزين مؤقت محلية قائمة على SSD، وهي ذاكرة تخزين مؤقت غير شاملة على النسخة المتماثلة للحساب.

استخدام ذاكرة التخزين المؤقت المحلية RBPEX

توجد ذاكرة التخزين المؤقت المحلية RBPEX في النسخة المتماثلة للحساب، على تخزين SSD المحلي. وبالتالي، فإن IO مقابل ذاكرة التخزين المؤقت هذه أسرع من IO مقابل خوادم الصفحات البعيدة. حالياً، يحتوي sys.dm_io_virtual_file_stats () في قاعدة بيانات Hyperscale على صف خاص يبلغ عن IO مقابل ذاكرة التخزين المؤقت RBPEX المحلية على النسخة المتماثلة للحساب. هذا الصف له القيمة 0 لكل من الأعمدة database_id وfile_id. على سبيل المثال، يقوم الاستعلام أدناه بإرجاع إحصائيات استخدام RBPEX منذ بدء تشغيل قاعدة البيانات.

select * from sys.dm_io_virtual_file_stats(0,NULL);

توفر نسبة القراءات التي تم إجراؤها على RBPEX إلى القراءات المجمعة التي تمت على جميع ملفات البيانات الأخرى نسبة عدد مرات دخول ذاكرة التخزين المؤقت لـ RBPEX. يتم عرض العداد RBPEX cache hit ratio أيضاً في عدادات الأداء DMV sys.dm_os_performance_counters.

قراءة البيانات

  • عندما يتم إصدار القراءات بواسطة محرك قاعدة بيانات SQL Server على نسخة متماثلة للحساب، فقد يتم تقديمها إما عن طريق ذاكرة التخزين المؤقت RBPEX المحلية، أو عن طريق خوادم الصفحة البعيدة، أو عن طريق مزيج من الاثنين في حالة قراءة صفحات متعددة.
  • عندما تقرأ النسخة المتماثلة للحساب بعض الصفحات من ملف معين، على سبيل المثال file_id 1، إذا كانت هذه البيانات موجودة فقط في ذاكرة التخزين المؤقت المحلية RBPEX، يتم حساب كل IO لهذه القراءة مقابل file_id 0 (RBPEX). إذا كان جزء من هذه البيانات موجوداً في ذاكرة التخزين المؤقت المحلية لـ RBPEX، وكان جزء ما موجوداً على خادم صفحة بعيد، فسيتم حساب (IO) تجاه file_id 0 للجزء الذي يتم تقديمه من RBPEX، ويتم احتساب الجزء الذي يتم تقديمه من خادم الصفحة البعيدة نحو file_id 1.
  • عندما تطلب نسخة متماثلة لحساب صفحة على LSN معين من خادم الصفحة، إذا لم يلتزم خادم الصفحة بـ LSN المطلوب، فستنتظر القراءة على النسخة المتماثلة للحساب حتى يكتشف خادم الصفحة الأمر من قبل أن يتم إرجاع الصفحة إلى النسخة المتماثلة للحساب. لأي قراءة من خادم الصفحة على النسخة المتماثلة للحساب، سترى نوع الانتظار PAGEIOLATCH_ex * إذا كان ينتظر IO. في Hyperscale، يتضمن وقت الانتظار هذا كلاً من وقت اللحاق بالصفحة المطلوبة على خادم الصفحة إلى LSN المطلوب، والوقت اللازم لنقل الصفحة من خادم الصفحة إلى نسخة الحساب المتماثلة.
  • غالباً ما تتم القراءات الكبيرة مثل القراءة المسبقة باستخدام قراءات "Scatter-Gather". يسمح هذا بقراءة ما يصل إلى 4 ميغابايت من الصفحات في المرة الواحدة، وتعتبر قراءة واحدة في محرك قاعدة بيانات SQL Server. ومع ذلك، عندما تكون البيانات التي تتم قراءتها في RBPEX، يتم حساب هذه القراءات على أنها قراءات فردية متعددة بحجم 8 كيلوبايت، نظراً لأن تجمع المخزن المؤقت وRBPEX دائماً ما يستخدمان صفحات 8 كيلوبايت. نتيجة لذلك، قد يكون عدد عمليات IOs التي تمت قراءتها مقابل RBPEX أكبر من العدد الفعلي لعمليات IOs التي يؤديها المحرك.

كتابة البيانات

  • النسخة المتماثلة الأساسية للحساب لا تكتب مباشرة إلى خوادم الصفحة. بدلاً من ذلك، تتم إعادة تشغيل سجلات السجل من خدمة السجل على خوادم الصفحة المقابلة.
  • تتم عمليات الكتابة التي تحدث على النسخة المتماثلة للحساب في الغالب إلى RBPEX المحلي (file_id 0). للكتابة على ملفات منطقية أكبر من 8 كيلوبايت، وبعبارة أخرى تلك التي تتم باستخدام تجميع-كتابة، تتم ترجمة كل عملية كتابة إلى عمليات كتابة فردية متعددة بحجم 8 كيلوبايت إلى RBPEX نظراً لأن تجمع المخزن المؤقت وRBPEX يستخدمان دائماً صفحات 8 كيلوبايت. ونتيجة لذلك، قد يكون عدد عمليات IOs المرئية مقابل RBPEX أكبر من العدد الفعلي لعمليات IOs التي يؤديها المحرك.
  • تُظهر أيضاً الملفات غير RBPEX، أو ملفات البيانات بخلاف file_id 0 التي تتوافق مع خوادم الصفحة، عمليات الكتابة. في طبقة الخدمة Hyperscale، تتم محاكاة هذه الكتابات، لأن النسخ المتماثلة للحوسبة لا تكتب أبداً مباشرة إلى خوادم الصفحة. يتم احتساب كتابة IOPS ومعدل النقل عند حدوثها في النسخة المتماثلة للحساب، لكن زمن الوصول لملفات البيانات بخلاف file_id 0 لا يعكس زمن الانتقال الفعلي لعمليات كتابة خادم الصفحة.

كتابة السجل

  • في الحساب الأساسي، يتم احتساب كتابة السجل في file_id 2 من sys.dm_io_virtual_file_stats. كتابة السجل على الحساب الأساسي هو كتابة إلى منطقة تسجيل الدخول.
  • لا تتم تقوية سجلات السجل على النسخة المتماثلة الثانوية في الالتزام. في Hyperscale، يتم تطبيق السجل بواسطة خدمة السجل على النسخ المتماثلة الثانوية بشكل غير متزامن. نظراً لأن عمليات الكتابة في السجل لا تحدث فعلياً في النسخ المتماثلة الثانوية، فإن أي محاسبة لسجلات IOs على النسخ المتماثلة الثانوية تكون لأغراض التعقب فقط.

بيانات IO في إحصاءات استخدام الموارد

في قاعدة بيانات غير Hyperscale، يتم دمج قراءة وكتابة IOPS مقابل ملفات البيانات، بالنسبة إلي إدارة الموارد في طرق العرض sys.dm_db_resource_stats وsys.resource_stats في العمود avg_data_io_percent. تم الإبلاغ عن نفس القيمة في مدخل Microsoft Azure كـ النسبة المئوية لإدخال البيانات.

في قاعدة بيانات Hyperscale، يُبلغ هذا العمود عن استخدام IOPS للبيانات بالنسبة إلى حد التخزين المحلي على النسخة المتماثلة المحسوبة فقط، وتحديداً IO مقابل RBPEX وtempdb. تشير القيمة 100٪ في هذا العمود إلى أن إدارة الموارد تقيد التخزين المحلي IOPS. إذا كان هذا مرتبطاً بمشكلة في الأداء، فاضبط حمل العمل لإنشاء عدد أقل من IO، أو قم بزيادة هدف خدمة قاعدة البيانات لزيادة الحد الأقصى لـIOPS الخاص بإدارة الموارد. بالنسبة لإدارة الموارد في RBPEX للقراءة والكتابة، يحسب النظام IOs الفردية ذات 8 كيلوبايت، بدلاً من IOs الأكبر التي قد يتم إصدارها بواسطة محرك قاعدة بيانات SQL Server.

لا يتم الإبلاغ عن بيانات IO مقابل خوادم الصفحات البعيدة في طرق عرض استخدام الموارد أو في المدخل، ولكن يتم الإبلاغ عنها في ،sys.dm_io_virtual_file_stats() DMF كما ذكرنا سابقاً.

الموارد الإضافية