السابق

التالي

التدريب - قياس أداء حمل العمل الخاص بك

مكتمل

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

يمكنك العثور على جميع البرامج النصية لهذا التمرين في المجلد 04-Performance\monitor_and_scale في مستودع GitHub الذي نسخته أو الملف المضغوط الذي قمت بتنزيله.

زيادة أداء Azure SQL

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

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

   بالنسبة إلى Azure، يمكنك استخدام ALTER DATABASEأو Azure CLI أو مدخل Microsoft Azure لزيادة سعة وحدة المعالجة المركزية دون ترحيل قاعدة البيانات من قبل المستخدم.

2. وباستخدام مدخل Microsoft Azure، فإنه يمكنك رؤية خيارات لكيفية قياس المزيد من موارد CPU. من جزء نظرة عامة على قاعدة البيانات، حدد مستوى التسعير للتوزيع الحالي. يسمح لك مستوى التسعير بتغيير مستوى الخدمة وعدد vCores.

   

3. وهنا يمكنك أن ترى خيارات لتغيير أو قياس موارد الحوسبة. للأغراض العامة، يمكنك بسهولة توسيع نطاق ما يصل إلى شيء مثل 8 vCores.

   

   يمكنك أيضًا استخدام طريقة مختلفة لقياس حمل العمل الخاص بك.

4. وبالنسبة إلى هذا التدريب، حتى تتمكن من رؤية الاختلافات الصحيحة في التقارير، فيجب أولاً مسح مخزن الاستعلام. في SQL Server Management Studio (SSMS)، حدد قاعدة بيانات AdventureWorks واستخدم القائمة File>Open>File. افتح البرنامج النصي flushhquerystore.sql في SSMS في سياق قاعدة بيانات AdventureWorks. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

   EXEC sp_query_store_flush_db;
   

   حدد Execute لتشغيل دفعة T-SQL هذه.

   إشعار

   يؤدي تشغيل الاستعلام السابق إلى مسح جزء الذاكرة من بيانات Query Store إلى القرص.

5. افتح البرنامج النصي get_service_objective.sql في SSMS. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

   SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
   FROM sys.dm_user_db_resource_governance;
   GO
   SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
   GO
   

   وهذه طريقة لمعرفة مستوى الخدمة عن طريق استخدام T-SQL. يعرف مستوى التسعير أو الخدمة أيضا باسم هدف الخدمة. حدد Execute لتشغيل دفعات T-SQL.

   وبالنسبة إلى نشر قاعدة البيانات Azure SQL الحالي، يجب أن تكون النتائج مثل الصورة التالية:

   

   لاحظ استخدام مصطلح slo_name أيضا لهدف الخدمة. slo يرمز إلى هدف مستوى الخدمة.

   لا يتم توثيق القيم المختلفة slo_name ، ولكن يمكنك أن ترى من قيمة السلسلة أن قاعدة البيانات هذه تستخدم طبقة خدمة للأغراض العامة مع اثنين من vCores:

   إشعار

   SQLDB_OP_... هي السلسلة المستخدمة للأعمال الهامة.

   عندما تقوم بعرض وثائق ALTER DATABASE فلاحظ القدرة على اختيار الهدف الخاص بك لنشر SQL Server وذلك للحصول على خيارات البنية الصحيحة. حدد SQL Database single database/elastic pool لمشاهدة خيارات قاعدة بيانات Azure SQL. لمطابقة مقياس الحساب الذي وجدته في المدخل، تحتاج إلى هدف 'GP_Gen5_8'الخدمة .

6. قم بتعديل هدف الخدمة لقاعدة البيانات إلى قياس المزيد من وحدات CPU. افتح البرنامج النصي modify_service_objective.sql في SSMS وقم بتشغيل دفعة T-SQL. يجب أن تبدو نافذة محرر الاستعلام الخاصة بك مثل النص التالي:

   ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
   

   يعود هذا الكشوف على الفور، ولكن يتم توسيع نطاق موارد الحوسبة في الخلفية. وينبغي أن يستغرق هذا القياس الصغير أقل من دقيقة، ولفترة قصيرة من الوقت تكون قاعدة البيانات غير متصلة لجعل التغيير فعالاً. يمكنك مراقبة تقدم نشاط القياس هذا عن طريق استخدام مدخل Microsoft Azure.

   

7. في مستكشف الكائنات، ضمن مجلد قواعد بيانات النظام، انقر بزر الماوس الأيمن فوق قاعدة البيانات الرئيسية وحدد استعلام جديد. قم بتشغيل هذا الاستعلام في محرر استعلام Management Studio:

   SELECT * FROM sys.dm_operation_status;
   

   وهذه طريقة أخرى لمراقبة التقدم الذي يحدثه تغيير هدف الخدمة لقاعدة بيانات Azure SQL. وتعرض طريقة عرض الإدارة الديناميكية (DMV) سجلات التغييرات التي تم إدخالها إلى قاعدة البيانات مع ALTER DATABASE إلى هدف الخدمة. ويعمل على إظهار تقدم التغيير النشط.

   وفيما يلي مثال عن إخراج DMV في شكل جدول بعد تشغيل كشف ALTER DATABASE السابق:

   الصنف	القيمة‬
   session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
   resource_type	0
   resource_type_desc	قاعدة بيانات
   major_resource_id	AdventureWorks
   minor_resource_id
   ‏‏التشغيل	ALTER DATABASE
   الحالة	1
   state_desc	قيد التنفيذ
   percent_complete	0
   error_code	0
   error_desc
   error_severity	0
   error_state	0
   start_time	[date time]
   last_modify_time	[date time]

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

8. عند القيام بذلك، استخدم الاستعلامات السابقة المدرجة من get_service_objective.sql في SSMS للتحقق من أن هدف الخدمة الجديد أو مستوى الخدمة من 8 vCores قد بدأ سريانه.

قم بتشغيل حمل العمل بعد الزيادة

والآن حيث إن قاعدة البيانات لديها المزيد من سعة وحدة CPU، فدعونا نقوم بتشغيل حمل العمل الذي قمنا به في العملية السابقة لملاحظة ما إذا كان هناك تحسن في الأداء.

1. والآن بعد أن تم الانتهاء من القياس، فتحقق مما إذا كانت مدة حمل العمل أسرع وما إذا كان الانتظار على موارد وحدة CPU قد انخفض. قم بتشغيل حمل العمل مرة أخرى باستخدام الأمر sqlworkload.cmd الذي قمت بتشغيله في التمرين السابق.

2. باستخدام SSMS، قم بتشغيل نفس الاستعلام من التمرين الأول من هذه الوحدة النمطية لمراقبة النتائج من البرنامج النصي dmdbresourcestats.sql:

   SELECT * FROM sys.dm_db_resource_stats;
   

   ينبغي أن ترى أن متوسط استخدام مورد CPU قد انخفض من استخدام ما يقرب من 100 في المئة في التدريب السابق. عادة، sys.dm_db_resource_stats يعرض ساعة واحدة من النشاط. يؤدي sys.dm_db_resource_stats تغيير حجم قاعدة البيانات إلى إعادة التعيين.

3. باستخدام SSMS، قم بتشغيل نفس الاستعلام من التمرين الأول من هذه الوحدة النمطية لمراقبة النتائج من البرنامج النصي dmexecrequests.sql.

   SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
   FROM sys.dm_exec_requests er
   INNER JOIN sys.dm_exec_sessions es
   ON er.session_id = es.session_id
   AND es.is_user_process = 1;
   

   سوف ترى أن هناك المزيد من الاستعلامات مع حالة RUNNING. وهذا يعني أن عمالنا لديهم قدرة أكبر على CPU لتنفيذها.

4. لاحظ المدة الجديدة لحمل العمل. يجب أن تكون مدة حمل العمل من sqlworkload.cmd الآن أقل بكثير، ويجب أن تكون حوالي 25-30 ثانية.

لاحظ تقارير مخزن الاستعلام

فلنقم بالنظر إلى نفس تقارير مخزن الاستعلام كما فعلنا في التدريب السابق.

1. باستخدام نفس التقنيات مثل التمرين الأول في هذه الوحدة النمطية، انظر إلى تقرير أهم استعلامات استهلاك الموارد من SSMS:

   

   سترى الآن استعلمين (query_id). هذا هو نفس الاستعلام، ولكنه يظهر كقيم مختلفة query_id في Query Store، لأن عملية المقياس تتطلب إعادة تشغيل وكان يجب إعادة التحويل البرمجي للاستعلام. يمكنك أن ترى في التقرير أن المدة الإجمالية والمتوسطة كانت أقل بكثير.

2. انظر أيضا إلى تقرير Query Wait Statistics وحدد شريط انتظار CPU. يمكنك رؤية أن متوسط وقت الانتظار العام للاستعلام أقل، وهي نسبة مئوية أقل من المدة الإجمالية. وهذا مؤشر جيد على أن وحدة CPU ليست بنفس القدر من ازدحام المواد عندما كان عدد قاعدة البيانات أقل من vCores:

   

3. يمكنك غلق كافة التقارير ونوافذ محرر الاستعلام. اترك SSMS متصلا، لأنك ستحتاج إليه في التمرين التالي.

قم بملاحظة التغييرات من مقاييس Azure

1. انتقل إلى قاعدة بيانات AdventureWorks في مدخل Microsoft Azure، وانظر إلى علامة التبويب Monitoring في جزء Overview مرة أخرى لاستخدام الحساب:

   

   ولاحظ أن المدة أقصر بالنسبة إلى الاستخدام العالي لوحدة CPU، ما يعني انخفاضًا إجماليًا في موارد وحدة CPU اللازمة لإدارة حمل العمل.

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

   

تلميح

فإذا واصلت لزيادة vCorres بقاعدة البيانات هذه، فإنه يمكنك تحسين الأداء حيث تكون كل الاستعلامات لديها الكثير من موارد وحدة CPU. وهذا لا يعني بأنه يجب عليك مطابقة عدد vCores مع عدد المستخدمين المتزامنين من حمل العمل الخاص بك. بالإضافة إلى ذلك، يمكنك تغيير "Pricing Tier" لاستخدام "Serverless Compute Tier"، بدلا من "Provisioned". وهذا يساعدك على تحقيق قياس تلقائي أكثر لحمل العمل. على سبيل المثال، إذا اخترت قيمة vCore 2 كحد أدنى لحمل العمل هذا والحد الأقصى لقيمة vCore البالغة 8، فسيتم تغيير حجم حمل العمل هذا على الفور إلى 8 vCores.

في التمرين التالي، ستلاحظ مشكلة في الأداء وتحلها من خلال تطبيق أفضل الممارسات لأداء التطبيق.

متابعة