it-swarm.asia

أوامر SQL Server لمسح ذاكرة التخزين المؤقت قبل تشغيل مقارنة الأداء

عند مقارنة وقت تنفيذ استعلامين مختلفين ، من المهم مسح ذاكرة التخزين المؤقت للتأكد من أن تنفيذ الاستعلام الأول لا يغير أداء الثاني.

في بحث Google ، يمكنني العثور على هذه الأوامر:

DBCC FREESYSTEMCACHE
DBCC FREESESSIONCACHE
DBCC FREEPROCCACHE

في الواقع ، تستغرق استفساراتي وقتًا أكثر واقعية لإكمالها بعد عدة عمليات إعدام من ذي قبل. ومع ذلك ، لست متأكدًا أن هذه هي التقنية الموصى بها.

ما هي أفضل ممارسة؟

49
andrerpena

شخصيًا ، بالنسبة للاستعلام المشترك ، فإن عمليات الإعدام الثانية والإعدامات اللاحقة لها أهمية أكبر.

هل تختبر القرص IO أو أداء الاستعلام؟

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

يمكنك اذا اردت:

  • DBCC DROPCLEANBUFFERS يمسح الصفحات النظيفة (غير المعدلة) من تجمع المخزن المؤقت
    يسبق ذلك بـ CHECKPOINT لمسح أي صفحات متسخة على القرص أولاً
  • DBCC FLUSHPROCINDB يمسح خطط التنفيذ لقاعدة البيانات هذه

انظر أيضًا (على DBA.SE)

45
gbn

إجابة متأخرة ولكن قد تكون مفيدة للقراء الآخرين

DBCC DROPCLEANBUFFERS هو أمر يستخدم غالبًا لاختبار الاستعلام وقياس سرعة تنفيذ الاستعلام. يترك هذا الأمر (عند التشغيل) وراء الصفحات المتسخة فقط ، وهو في الواقع جزء صغير من البيانات. يزيل كل الصفحات النظيفة لخادم كامل.

يرجى العلم بأن هذا الأمر لا لا يعمل في بيئة الإنتاج. سيؤدي تشغيل هذا الأمر إلى ذاكرة تخزين مؤقت فارغة في الغالب. عند تشغيل أي استعلام بعد تنفيذ الأمر DBCC DROPCLEANBUFFERS ، سيستخدم القراءات الفعلية لإعادة البيانات إلى ذاكرة التخزين المؤقت ، والتي من المحتمل أن تكون أبطأ بكثير من الذاكرة.

مرة أخرى ، تعامل مع هذا الأمر بشكل مشابه لـ DBCC FREEPROCCACHE - لا يجب تشغيله على أي خادم إنتاج إلا إذا كنت تعرف تمامًا ما تفعله.

يمكن أن يكون هذا أداة تطوير مفيدة لأنه يمكنك تشغيل استعلام في بيئة اختبار الأداء مرارًا وتكرارًا دون أي تغييرات في السرعة/الكفاءة بسبب التخزين المؤقت للبيانات في الذاكرة.

تعرف على المزيد على: http://www.sqlshack.com/insight-into-the-sql-server-buffer-cache/

15
Thomas Bovee

قيل لي دائما أن استخدام:

dbcc dropcleanbuffers;

من MSDN :

استخدم DROPCLEANBUFFERS DBCC لاختبار الاستعلامات باستخدام ذاكرة التخزين المؤقت على البارد دون إيقاف تشغيل الخادم وإعادة تشغيله.

لإفلات المخازن المؤقتة النظيفة من تجمع المخزن المؤقت ، استخدم أولاً CHECKPOINT لإنتاج ذاكرة تخزين مؤقت باردة. هذا يفرض كتابة جميع الصفحات القذرة لقاعدة البيانات الحالية على القرص وتنظيف المخازن المؤقتة. بعد القيام بذلك ، يمكنك إصدار الأمر DROPCLEANBUFFERS DBCC لإزالة كافة المخازن المؤقتة من تجمع المخزن المؤقت.

10
DaveShaw

الإجابات الأخرى صحيحة حول أسباب لا تشغيل DBCC FREEPROCCACHE. ومع ذلك ، هناك أيضًا سببان للقيام بذلك:

  1. التناسق

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

إذا كنت ترغب في اختبار أداء ذاكرة التخزين المؤقت السريع ، فتأكد من تشغيل الاستعلامات عدة مرات ، والتبديل ، وتجاهل أول تشغيلين. متوسط ​​النتائج.

  1. أسوأ حالة أداء

لنفترض أن لديك طلب بحث يستغرق ثانية واحدة مقابل ذاكرة تخزين مؤقت ساخنة ولكن دقيقة واحدة مقابل ذاكرة تخزين مؤقت باردة. يمكن أن يكون التحسين الذي يجعل الاستعلام داخل الذاكرة أبطأ بنسبة 20٪ ولكن الاستعلام المرتبط بـ IO أسرع بنسبة 20٪ هو فوز كبير: خلال العمليات العادية ، لن يلاحظ أحد 200 مللي ثانية إضافية في الظروف العادية ، ولكن إذا كان هناك شيء يفرض الاستعلام على تشغيل على القرص ، قد يستغرق حفظ 48 ثانية بدلاً من 60 عملية بيع.

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

3
Jon of All Trades