وصف إحصائيات الانتظار

مكتمل

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

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

يتم تقسيم إحصائيات الانتظار إلى ثلاثة أنواع من حالات الانتظار: حالات انتظار المورد و حالات الانتظار و حالات الانتظار الخارجي.

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

يمكنك التحقق من sys.dm_os_wait_stats طريقة عرض النظام لاستكشاف جميع الانتظارات التي واجهتها مؤشرات الترابط التي تم تنفيذها، و sys.dm_db_wait_stats قاعدة بيانات Azure SQL. تسرد sys.dm_exec_session_wait_stats طريقة عرض النظام جلسات الانتظار النشطة.

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

يتم تقييم إحصائيات الانتظار كنسبة مئوية من إجمالي عدد حالات الانتظار على الخادم.

تُظهر sys.dm_os_wait_stats نتيجة هذا الاستعلام من نوع الانتظار، وتجميع النسبة المئوية لوقت الانتظار (عمود Wait Percentage) ومتوسط وقت الانتظار بالثواني لكل نوع انتظار.

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

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

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

هناك عدة أنواع من الانتظار المتاحة في SQL Server، ولكن بعضها شائع.

• RESOURCE_SEMAPHORE— يشير إلى أن الاستعلامات تنتظر توفر الذاكرة، وغالبا ما يكون ذلك بسبب منح الذاكرة الزائدة لاستعلامات معينة. تظهر هذه المشكلة عادة كأوقات تشغيل استعلام طويلة أو حتى مهلات. يمكن أن تتضمن أسباب أنواع الانتظار هذه إحصائيات قديمة، والفهارس المفقودة، وتزامن الاستعلام العالي.

• LCK_M_X — يشير بشكل متكرر إلى وجود مشكلة حظر. يمكن حل هذه المشكلة عن طريق التغيير إلى READ COMMITTED SNAPSHOT مستوى العزل، أو تحسين الفهرسة لتقليل أوقات المعاملات، أو تحسين إدارة المعاملات داخل التعليمات البرمجية T-SQL.

• PAGEIOLATCH_SH — يمكن أن يشير نوع الانتظار هذا إلى وجود مشكلات في الفهارس أو عدم وجود فهارس مفيدة، مما يؤدي إلى فحص SQL Server كميات زائدة من البيانات. بدلا من ذلك، إذا كان عدد الانتظار منخفضا ولكن وقت الانتظار مرتفعا، فقد يقترح مشاكل في أداء التخزين. يمكنك مراقبة هذا السلوك عن طريق تحليل البيانات في waiting_tasks_count العمودين و wait_time_ms في sys.dm_os_wait_stats طريقة عرض النظام لحساب متوسط وقت الانتظار لنوع انتظار معين.

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

• CXPACKET— يمكن أن يشير التكرار العالي لنوع الانتظار هذا إلى تكوين غير صحيح. قبل SQL Server 2019، كان الإعداد الافتراضي لدرجة التوازي القصوى (MAXDOP) هو استخدام جميع وحدات المعالجة المركزية المتوفرة للاستعلامات. بالإضافة إلى ذلك، تم تعيين حد التكلفة للتوازي إلى 5، مما قد يؤدي إلى تنفيذ استعلامات صغيرة بالتوازي، ما يحد من معدل النقل. لتقليل نوع الانتظار هذا، يمكنك خفض إعداد MAXDOP وزيادة حد التكلفة للتوازي. ومع ذلك، يمكن أن يشير نوع الانتظار CXPACKET أيضا إلى استخدام عال لوحدة المعالجة المركزية، والذي يتم حله عادة من خلال ضبط الفهرس.

• PAGEIOLATCH_UP — يمكن أن يشير نوع الانتظار هذا على صفحات البيانات 2:1:1 إلى تنازع TempDB على صفحات بيانات مساحة خالية من الصفحة (PFS). يحتوي كل ملف بيانات على صفحة PFS لكل 64 ميجابايت تقريبًا من البيانات. يحدث هذا الانتظار عادة بسبب وجود ملف TempDB واحد فقط، كما هو الحال قبل SQL Server 2016، كان السلوك الافتراضي هو استخدام ملف بيانات واحد ل TempDB. أفضل ممارسة ل TempDB هي استخدام ملف واحد لكل ذاكرة أساسية لوحدة المعالجة المركزية، ما يصل إلى ثمانية ملفات. من المهم أيضًا التأكد من أن ملفات بيانات TempDB بنفس الحجم ولها نفس إعدادات التزايد التلقائي لضمان استخدامها بالتساوي. يتحكم إصدار SQL Server 2016 والإصدارات الأعلى في تزايد ملفات بيانات TempDB لضمان زيادتها بطريقة متسقة ومتزامنة.

بالإضافة إلى DMVs المذكورة سابقا، يتعقب Query Store أيضا الانتظارات المقترنة باستعلامات محددة. على الرغم من أن بيانات الانتظار التي يتم تعقبها بواسطة Query Store ليست دقيقة مثل البيانات في DMVs، إلا أنها لا تزال توفر نظرة عامة مفيدة حول ما ينتظره الاستعلام.