حجم VM: أفضل ممارسات الأداء لـ Microsoft SQL Server على VM من Azure

ينطبق على: Microsoft SQL Server على Azure VM

توفر هذه المقالة معلومات لتجميع الخط الأساسي للأداء كسلسلة من أفضل الممارسات والإرشادات؛ لتحسين أداء Microsoft SQL Server على أجهزة Azure الظاهرية (VMs).

عادة ما يكون هناك مفاضلة بين تحسين التكاليف، وتحسين الأداء. تركز سلسلة أفضل الممارسات على الحصول على ⁧⁩أفضل⁧⁩ أداء لـ Microsoft SQL Server على VM Azure. إذا كان حمل عملك أقل تطلبًا، فقد لا تحتاج إلى كل تحسين موصى به. يؤخذ في الاعتبار احتياجات الأداء والتكاليف، وأنماط حمل العمل أثناء تقييم هذه التوصيات.

نظرة عامة

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

ابدأ بتجميع CPU، والذاكرة ⁧⁩، وIOPS⁧⁩، و⁧⁩ معدل النقل⁧⁩، و⁧⁩ زمن وصول⁧⁩ حمل العمل المصدر في أوقات الذروة بعد قائمة التحقق من أداء ⁧⁩التطبيق⁧⁩.

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

استخدم تحليل الأداء لتحديد ⁧⁩حجم VM⁧⁩ الذي يمكن أن يتدرج إلى متطلبات أداء حمل العمل.

التخزين

يعتمد أداء Microsoft SQL Server بشكل كبير على النظام الفرعي I/O، ويتم قياس أداء التخزين بواسطة IOPS، ومعدل النقل. ما لم تتناسب قاعدة البيانات الخاصة بك مع الذاكرة الفعلية، يقوم Microsoft SQL Server باستمرار بإحضار صفحات قاعدة البيانات داخل وخارج مجمعات المخزن المؤقت. يجب التعامل مع ملفات البيانات Microsoft SQL Server بشكل مختلف. يكون الوصول إلى ملفات السجل تسلسليًا، إلا في حالة الحاجة إلى التراجع عن المعاملة؛ حيث يتم الوصول إلى ملفات البيانات، بما في ذلك tempdb، بشكل عشوائي. إذا كان لديك نظام فرعي I/O بطيء، فقد يواجه المستخدمون مشكلات في الأداء؛ مثل: أوقات الاستجابة البطيئة، والمهام التي لا تكتمل بسبب المهلات.

تحتوي VM في Microsoft Azure Marketplace على ملفات سجل على قرص فعلي منفصل عن ملفات البيانات بشكل افتراضي. تتوافق ملفات بيانات tempdb مع حجمها مع أفضل الممارسات، وتستهدف محرك الأقراص المؤقت ⁧D:\⁩.

يمكن أن تساعد عدادات PerfMon التالية في التحقق من صحة معدل النقل عمليات إخراج الـ IO المطلوبة من قبل Microsoft SQL Server:

  • ⁩\LogicalDisk\ القرص يقرأ/ ثانية⁧⁩ (قراءة IOPS)
  • ⁩\LogicalDisk\القرص يقرأ/ ثانية⁧⁩ (كتابة IOPS)
  • ⁩ \ Logical Disk \ Disk Read Bytes / Sec ⁧⁩ (اقرأ متطلبات معدل النقل البيانات، والسجلات، وملفات tempdb)
  • ⁩ \ Logical Disk \ Disk Read Bytes / Sec ⁧⁩ (اقرأ متطلبات معدل النقل البيانات، والسجلات، وملفات tempdb)

باستخدام IOPS، ومتطلبات معدل النقل عند مستويات الذروة، قم بتقييم أحجام VM التي تطابق السعة من قياساتك.

إذا كان حمل العمل الخاص بك يتطلب 20 كيلو بايت لقراءة IOPS و10 كيلو بايت IOPS، يمكنك إما اختيار E16s_v3 (مع ما يصل إلى 32 كيلو بايت مخبأ و 25600 IOPS غير مؤقت)، أو M16_s (مع ما يصل إلى 20 كيلو بايت مخبأ، و10 كيلو بايت IOPS غير مؤقت) مع 2 أقراص P30 مخططة باستخدام موقع التخزين.

تأكد من فهم متطلبات الإنتاجية، وIOPS لحمل العمل حيث إن VMs لها حدود مقياس مختلفة لـ IOPS، ومعدل النقل.

ذاكرة

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

يمكن أن تساعد عدادات PerfMon التالية في التحقق من صحة ذاكرة VM Microsoft SQL Server:

Compute

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

هذا ليس تحديًا في Azure حيث VM جديد على سلسلة مختلفة من الأجهزة، وحتى في منطقة مختلفة، من السهل تحقيقه.

في Azure، تريد الاستفادة من موارد VM قدر الإمكان؛ لذلك، يجب تكوين الأجهزة الظاهرية Azure؛ للحفاظ على متوسط CPU أعلى مستوى ممكن دون التأثير على حمل العمل.

يمكن أن تساعد عدادات PerfMon التالية في التحقق من صحة ذاكرة VM Microsoft SQL Server:

  • \Processor Information(_Total)% Processor Time
  • \Process(sqlservr)% Processor Time

ملاحظة

من الناحية المثالية، حاول أن تهدف إلى استخدام 80 ٪ من الحساب الخاصة بك، مع قمم فوق 90 ٪؛ ولكن لا تصل إلى 100 ٪ لأي وقت مستدام من الزمن. بشكل أساسي، ما عليك سوى توفير الحساب الذي يحتاجه التطبيق، ثم التخطيط لتوسيع نطاق العمل أو خفضه حسب ما تتطلبه الأعمال.

الخطوات التالية

لمعرفة المزيد، راجع المقالات الأخرى في هذه السلسلة من أفضل الممارسات:

للحصول على أفضل ممارسات الأمان، راجع⁧⁩ اعتبارات الأمان Microsoft SQL Server على VM Azure⁧⁩.

راجع مقالات Microsoft SQL ServerVirtual Machine الأخرى في ⁧⁩ نظرة عامة على Microsoft SQL Server على Azure Virtual Machines ⁧⁩. إذا كانت لديك أسئلة حول أجهزة SQL Server الظاهرية، فراجع ⁧⁩الأسئلة المتداولة⁧⁩.