كيفية مراقبة موارد AWS RDS SQL Server Express واستهلاك العامل قبل الطلب

كيفية مراقبة موارد AWS RDS SQL Server Express واستهلاك العامل قبل الطلب

هل تواجه مشكلة في تشغيل اثنين من مثيلات RDS لـ SQL Server Express بنفس الإصدار (مثل sqlserver-ex 16.00.4185.3) على نفس نوع الجهاز (db.t3.small، بثماني نوى ووحدة تخزين موحدة)؟ أحدهما يستخدم حوالي 60-64% من وحدة المعالجة المركزية بشكل مستمر، بينما الآخر يستريح عند حوالي 10%. إليك طريقة لفهم هذه المشكلة وحلها بسهولة.

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

لفهم هذه العمليات، يمكن مراجعة الشفرات عبر أدوات مثل “sys.dm_os_threads”. نتوصل إلى أن حوالي نصف استخدام CPU يأتي من اثنين من خيوط العمل، ويبدوان كأنهما يبدأان مباشرة عند تشغيل الخادم. أحدهما يسمى “PREEMPTIVE_XE_CALLBACKEXECUTE”، وهو مسؤول عن تنفيذ أحداث “Extended Events”، التي تستخدم لمراقبة أداء النظام. وجوده بكثرة يدل على أن النظام ينشئ هذا النوع من العمليات بشكل متكرر، بشكل طبيعي، وقد يكون سبب في تحميل وحدة المعالجة بشكل غير مفهوم.

هذه الحالة تظهر بشكل واضح عندما تقارن بين النسختين، فواحدة تستخدم أكثر من الأخرى في عمليات “Preemptive Tasks”، رغم أن إعدادات الذاكرة والخدمات الأخرى متشابهة جدًا، ولا توجد أدوات أو إعدادات خاصة تفسر ذلك. حتى أن عدد الأحداث الخاصة بالمراقبة (Extended Events) مكتوب بشكل مشابه، والفروقات لا تفسر الاستخدام العالي لوحدة المعالجة.

لمعالجة المشكلة، يمكن أن تتبع خطوات بسيطة، وأولها هو مراقبة العمليات الجارية، والتأكد من أن المهام “Preemptive” ليست سببًا رئيسيًا للاستخدام العالي. إذا كانت العمليات كثيرة جدًا، فهذا قد يتطلب تحديث أو ضبط إعدادات النظام أو التطبيقات التي تتسبب في هذه العمليات. كما يمكنك إعادة تشغيل الخادم لمراقبة إن كانت الحالة مؤقتة، حيث إن الأمر يبدو أنه قابل للعكس ويتكرر.

أما بالنسبة للأسئلة التي تطرحها، فهي منطقية جدًا. فكيف يمكن لعملية “Preemptive_XE_CALLBACKEXECUTE” أن تتكرر بهذا الشكل، وما الذي يحافظ على استهلاك الموارد بهذه النسبة في وجود ذاكرة كافية؟ وهل يختلف الأمر في إصدارات مختلفة من SQL Server، مثل 15.00.4480.2 مقابل 16.00.4185.3؟ وأخيرًا، هل هناك أدوات يمكن استخدامها لمراقبة هذه العمليات بشكل أدق، بدلاً من الاعتماد على تفريغات البيانات فقط؟

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

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