استكشاف سيناريوهات الأداء

  • 5 دقائق

لتحديد كيفية استخدام أدوات الأداء وقدراته، من المهم النظر في أداء Azure SQL من خلال السيناريوهات.

فهم سيناريوهات الأداء الشائعة

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

الرسم التخطيطي للتشغيل في مقابل الانتظار.

أولاً، قم بالنظر إلى الاستخدام العام للمورد. لنشر SQL Server قياسي، يمكنك استخدام أدوات مثل مراقبة الأداء في Windows أو أعلى في Linux. وبالنسبة إلى Azure SQL فإنه يمكنك استخدام الطرق التالية:

  • مدخل Microsoft Azure/ وPowerShell/والتنبيهات

    ويحتوي Azure Monitor على مقاييس متكاملة لعرض استخدام الموارد لـ Azure SQL. ويمكنك أيضًا القيام بإعداد التنبيهات للبحث عن شروط استخدام الموارد.

  • sys.dm_db_resource_stats

    وبالنسبة إلى قاعدة بيانات Azure SQL، يمكنك النظر إلى DMV هذه لرؤية استخدام مورد CPU والذاكرة وI/O لنشر قاعدة البيانات. وتقوم DMV هذه بأخذ لقطة من هذه البيانات كل 15 ثانية.

  • sys.server_resource_stats

    يعمل DMV هذا تماما مثل sys.dm_db_resource_stats، ولكنه يستخدم لمشاهدة استخدام الموارد لمثيل SQL المدار لوحدة المعالجة المركزية والذاكرة والإداء/الإخراج. وتقوم DMV هذه أيضًا بأخذ لقطة كل 15 ثانية.

  • sys.dm_user_db_resource_governance

    وبالنسبة إلى قاعدة بيانات Azure SQL، تقوم DMV بإرجاع إعدادات التكوين الفعلي وإعدادات القدرة المستخدمة من قبل آليات إدارة الموارد في قاعدة البيانات الحالية أو في التجمّع المرن.

  • sys.dm_instance_resource_governance

    بالنسبة إلى مثيل Azure SQL المدار، يقوم DMV هذا بإرجاع معلومات مشابهة مثل sys.dm_user_db_resource_governance، ولكن لمثيل SQL المدار الحالي.

قيد التشغيل

إذا كنت قد حددت أن المشكلة هي ارتفاع استخدام معالج CPU، فهذا يسمى سيناريو التشغيل. ويمكن أن يتضمن سيناريو التشغيل الاستعلامات التي تستهلك الموارد من خلال التجميع أو التنفيذ. قم باستخدام الأدوات التالية للقيام بالمزيد من التحليل:

  • متجر الاستعلام

    قم باستخدام تقارير المورد الأعلى استهلاكًا في Management Studio أو طرق عرض كتالوج مخزن الاستعلام أو رؤية أداء الاستعلام في مدخل Microsoft Azure (قاعدة بيانات Azure SQL فقط) لإيجاد الاستعلامات التي تقوم باستهلاك معظم موارد وحدة معالج CPU.

  • sys.dm_exec_requests

    قم باستخدام DMV في Azure SQL لكي تحصل على لقطة من حالة الاستعلامات النشطة. ابحث عن الاستعلامات ذات الحالة RUNNABLE ونوع SOS_SCHEDULER_YIELD انتظار لمعرفة ما إذا كانت لديك سعة CPU كافية.

  • sys.dm_exec_query_stats

    ويمكن أن تُستخدم DMV كثيرًا مثل مخزن استعلام للعثور على أعلى الاستعلامات لاستهلاك الموارد. وهو متاح فقط لخطط الاستعلام المخزنة مؤقتا، بينما يوفر Query Store سجلا تاريخيا مستمرا للأداء. وتسمح لك DMV أيضًا بالعثور على خطة الاستعلام من أجل الاستعلام الذي تم تخزينه.

  • sys.dm_exec_procedure_stats

    يوفر DMV هذا معلومات تشبه sys.dm_exec_query_statsإلى حد كبير ، باستثناء معلومات الأداء التي يمكن عرضها على مستوى الإجراء المخزن.

    وبعد أن تقوم بتحديد الاستعلام أو الاستعلامات التي تستهلك أكثر الموارد، فقد تحتاج إلى فحص ما إذا كان لديك موارد CPU كافية لحمل العمل الخاص بك. وقد تقوم بتصحيح خطط الاستعلام باستخدام أدوات مثل جمع معلومات الاستعلام الخفيف أو كشوف SET أو مخزن الاستعلام أو تتبع الأحداث الممتدة.

قيد الانتظار‬

إذا لم تظهر المشكلة الخاصة بك كاستخدام عالٍ لمورد CPU، فقد تكون مشكلة الأداء تتضمن الانتظار للمورد. وتشمل السيناريوهات التي تتضمن الانتظار للمورد ما يلي:

  • انتظار I/O
  • انتظار التأمين
  • مهلة الحماية المؤقتة
  • حدود ذاكرة التخزين المؤقت
  • تخصيصات الذاكرة
  • خطة إخلاء الذاكرة المؤقتة

لإجراء تحليل لسيناريوهات الانتظار، عادة ما تنظر إلى الأدوات التالية:

  • sys.dm_os_wait_stats

    قم باستخدام DMV لمعرفة أعلى أنواع الانتظار لقاعدة البيانات أو للمثيل. وهذا يمكن أن يوجهك إلى الإجراء التالي، وفقًا لأنواع الانتظار الأعلى.

  • sys.dm_exec_requests

    استخدم DMV هذا للعثور على أنواع انتظار محددة للاستعلامات النشطة لمعرفة المورد الذي تنتظره. وهذا يمكن أن يكون سيناريو حظر قياسي، ويكون في انتظار عمليات تأمين من المستخدمين الآخرين.

  • sys.dm_os_waiting_tasks

    يمكنك استخدام DMV هذا للعثور على أنواع انتظار لمهمة معينة لاستعلام معين يتم تنفيذه حاليا، ربما لمعرفة سبب استعلام يستغرق وقتا أطول من المعتاد. sys.dm_os_waiting_tasks يحتوي على إحصائيات الانتظار المباشر التي sys.dm_os_wait_stats التجميعات بمرور الوقت.

  • متجر الاستعلام

    يقوم مخزن الاستعلام بتوفير تقارير وطرق عرض القائمة التي تقوم بعرض تجميع أعلى مرات انتظار لتنفيذ خطة الاستعلام. من المهم معرفة أن انتظار وحدة المعالجة المركزية يعادل مشكلة قيد التشغيل .

السيناريوهات الخاصة بـ Azure SQL

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

إدارة السجلات

يمكن أن تقوم Azure SQL باستخدام إدارة معدل التسجيل لفرض حدود الموارد على استخدام سجلات المعاملات. وقد تكون بحاجة إلى هذا الفرض لضمان حدود الموارد وتنفيذ اتفاقية SLA الموعودة. ويمكن النظر إلى إدارة السجلات من خلال أنواع الانتظار التالية:

  • LOG_RATE_GOVERNOR: ينتظر قاعدة بيانات Azure SQL
  • POOL_LOG_RATE_GOVERNOR: ينتظر التجمعات المرنة
  • INSTANCE_LOG_GOVERNOR: ينتظر مثيل Azure SQL المدار
  • HADR_THROTTLE_LOG_RATE*: ينتظر زمن انتقال الأعمال الحرجة والنسخ المتماثل الجغرافي

الحدود الخاصة بالعامل

يستخدم SQL Server مجموعة من العمال ولكن لديها حدود لأقصى عدد من العمال. قد تقترب التطبيقات التي تضم عددا كبيرا من المستخدمين المتزامنين من حدود العامل المفروضة لقاعدة بيانات Azure SQL ومثيل SQL المدار:

  • ولدى قاعدة بيانات Azure SQL حدود استنادًا إلى مستوى الخدمة وحجمها. فإذا تجاوزت هذا الحد، يتلقى الاستعلام الجديد خطأ.
  • في الوقت الحالي، يستخدم max worker threadsSQL Managed Instance ، لذلك قد يرى THREADPOOL العمال الذين تجاوزوا هذا الحد حالات انتظار.

انتظار HADR للأعمال التجارية الحرجة

فإذا كنت تقوم باستخدام مستوى خدمة الأعمال الحرجة، فقد ترى بشكل غير متوقع أنواع الانتظار التالية:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

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

مقياس فائق

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

في التمرين التالي، ستتعلم كيفية مراقبة مشكلة أداء Azure SQL وحلها باستخدام الأدوات والمعرفة التي اكتسبتها في هذه الوحدة.