مراقبة أداء المعالج والذاكرة وتحليل الاختناقات (I/O Wait, CPU Throttling)

مراقبة أداء المعالج والذاكرة وتحليل الاختناقات I/O Wait و CPU Throttling

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

إذا كنت قد اطّلعت سابقاً على مقال فهم العمليات (Processes) ومراقبة استهلاك الموارد (top, htop, ps, kill)، فهذه المقالة تمثل خطوة أعمق نحو قراءة مؤشرات الأداء بدقة وربطها بسلوك النظام الحقيقي. كما ترتبط بشكل مباشر مع تحسين أداء النظام (Performance Tuning) وحل المشكلات المتقدمة (Troubleshooting) لفهم جذور البطء لا أعراضه فقط.

ما الذي نراقبه فعلياً عند تحليل الأداء؟

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

• استهلاك CPU: هل الأنوية مشغولة بحمل حقيقي أم بانتظار موارد أخرى؟
• استهلاك RAM وSwap: هل النظام يستهلك الذاكرة بكفاءة أم بدأ التبديل إلى القرص؟
• قيمة I/O Wait: هل العمليات جاهزة للتنفيذ لكنها معلقة بسبب بطء التخزين؟
• الاختناق الحراري أو الطاقي CPU Throttling: هل المعالج خفّض تردده لحماية نفسه أو بسبب إعدادات الطاقة؟

قراءة حالة المعالج والذاكرة بسرعة

أول خطوة عملية هي الحصول على لقطة فورية عن الحمل العام. أوامر مثل top وhtop ممتازة، لكن يجب فهم أرقامها لا الاكتفاء بمظهرها. ويمكن الرجوع إلى الدخول الأول إلى الطرفية (Terminal): الأوامر الأساسية والمساعدة (man, help) إذا كنت تريد توسيع فهمك لخيارات هذه الأدوات.

top
free -h
vmstat 1 5
mpstat -P ALL 1 3

يفيد الأمر free -h في قراءة الذاكرة الفعلية والمتاحة، بينما يعرض vmstat مؤشرات مهمة مثل r وb إضافة إلى wa الذي يرمز إلى انتظار الإدخال والإخراج.

كيف نفسر الأرقام؟

• إذا كانت قيمة us وsy مرتفعة، فالمعالج يعمل فعلياً على تنفيذ مهام المستخدم أو النظام.
• إذا كانت قيمة wa مرتفعة، فهذه إشارة إلى أن البطء قد يكون من التخزين لا من المعالج.
• إذا امتلأت الذاكرة وبدأ استخدام swap بكثافة، فغالباً ستلاحظ تباطؤاً عاماً حتى لو لم يكن استهلاك المعالج عالياً.

فهم اختناق I/O Wait ولماذا هو خادع

يقصد بـ I/O Wait الوقت الذي تكون فيه الأنوية جاهزة للعمل، لكنها تنتظر استجابة من القرص أو وحدة التخزين. لذلك قد ترى الخادم بطيئاً جداً رغم أن استهلاك CPU الظاهري ليس مرتفعاً.

يظهر هذا النوع من الاختناق عادةً في قواعد البيانات، أنظمة النسخ الاحتياطي، ضغط الملفات، أو عند العمل على أقراص ممتلئة أو بطيئة. كما يرتبط بشكل وثيق بمفاهيم التخزين التي تناولناها في التعامل مع الأقراص والتخزين (Storage, Partitions, LVM).

iostat -xz 1 5
iotop
sar -d 1 5

الأمر iostat -xz مهم جداً لأنه يكشف مؤشرات مثل %util وawait. عندما تكون قيمة await مرتفعة باستمرار، فهذا يعني أن الطلبات تنتظر وقتاً طويلاً على القرص.

ارتفاع load average لا يعني دائماً ضغطاً على المعالج. قد يكون السبب طوابير انتظار على القرص، لذلك يجب ربط الحمل مع قيم wa وبيانات التخزين قبل اتخاذ أي قرار.

متى تكون الذاكرة هي سبب البطء؟

ذاكرة لينكس تُستخدم بذكاء، لذا امتلاء الذاكرة ليس مشكلة بحد ذاته. المشكلة تبدأ عندما يصبح النظام مضطراً لتحرير الصفحات باستمرار أو استخدام swap بشكل مستمر. عندها تتحول عمليات القراءة والكتابة إلى القرص، ويظهر البطء على شكل تأخر في الاستجابة أو تجمد مؤقت.

free -h
vmstat 1 5
cat /proc/meminfo | grep -E 'MemAvailable|SwapTotal|SwapFree'

إذا كانت قيمة si وso في vmstat غير صفرية بشكل متكرر، فهذا يعني أن النظام يبدّل الصفحات من وإلى القرص، وهي علامة كلاسيكية على ضغط الذاكرة.

ما هو CPU Throttling وكيف نكتشفه؟

CPU Throttling هو خفض سرعة المعالج تلقائياً عند ارتفاع الحرارة، أو عند وجود قيود طاقة، أو بسبب إعدادات governor غير مناسبة. النتيجة أن النظام يبدو تحت ضغط حتى لو لم تكن نسبة الاستهلاك 100% طوال الوقت.

lscpu
cpupower frequency-info
sensors
dmesg | grep -i -E 'thermal|throttl'

يعرض cpupower frequency-info الترددات الحالية والحاكم المستخدم، بينما تساعد أداة sensors في قراءة درجات الحرارة. أما الرسائل المسجلة في dmesg أو السجلات، فهي مهمة جداً، ويمكن تعميق هذه النقطة عبر مقال مراقبة السجلات (Logs) وتحليل الأخطاء (journalctl, /var/log).

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

منهجية عملية لتشخيص الاختناق

أفضل طريقة ليست تشغيل عشرات الأوامر عشوائياً، بل اتباع تسلسل منطقي مختصر:

1. افحص الحمل العام باستخدام top أو htop.
2. تحقق من الذاكرة وswap عبر free وvmstat.
3. إذا كانت قيمة wa مرتفعة، فانتقل فوراً إلى أدوات التخزين مثل iostat وiotop.
4. إذا كانت الحرارة مرتفعة أو التردد منخفضاً بشكل غير طبيعي، فافحص CPU Throttling.
5. راجع العمليات أو الخدمات المسببة للحمل، وهنا يفيد أيضاً مقال إدارة الخدمات باستخدام (systemd) و (systemctl) لتتبع الخدمات النشطة وإعادة ضبطها عند الحاجة.

نصائح عملية لتحسين الأداء بعد التشخيص

• انقل الأحمال الكثيفة من أقراص بطيئة إلى وحدات SSD أو حسّن طبقة التخزين.
• خفف الضغط على الذاكرة عبر تحسين التطبيقات أو زيادة RAM.
• راقب الخدمات الدورية ومهام الصيانة، خاصة المجدولة عبر جدولة المهام التلقائية باستخدام (Cron Jobs) إذا كانت تتسبب بقفزات مفاجئة في الاستهلاك.
• حسّن التبريد أو إعدادات الطاقة إذا ثبت وجود throttling.
• اعتمد أدوات مراقبة مستمرة مثل مراقبة النظام والخدمات (Monitoring) باستخدام Prometheus و Grafana بدلاً من الاكتفاء بالفحص اليدوي وقت الأزمة.

الخلاصة

مراقبة الأداء الحقيقية في لينكس تقوم على الربط بين مؤشرات متعددة، لا على قراءة رقم واحد معزول. ارتفاع الحمل قد يكون بسبب المعالج، أو الذاكرة، أو التخزين، أو حتى خفض تردد المعالج لحمايته. لذلك فإن فهم I/O Wait وCPU Throttling يمنحك رؤية أدق بكثير من الاكتفاء بنسبة استخدام CPU وحدها.

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