مقدمة في مراقبة أداء لينكس المتقدمة
مراقبة السيرفر لا تقتصر على معرفة مساحة القرص المتبقية أو نسبة استخدام المعالج. كمحترف هندسة أنظمة، يجب أن تفهم بدقة كيف تتفاعل النواة (Kernel) مع العتاد (Hardware). الأداء الجيد يعني استجابة فورية لطلبات المستخدمين، وتأخيراً لا يذكر في العمليات الخلفية.
تفكيك لغز الـ Load Average
عند تنفيذ الأمر uptime أو top، ستلاحظ دائماً أرقاماً مثل: load average: 1.20, 0.95, 0.85. ماذا تعني هذه الأرقام تحديداً؟
هذه الأرقام تمثل متوسط الحمل على المعالج خلال (دقيقة واحدة، 5 دقائق، 15 دقيقة) بالترتيب.
- في سيرفر أحادي النواة (1 Core): الرقم 1.0 يعني أن المعالج يعمل بكامل طاقته (100%). الرقم 2.0 يعني أن المعالج يعمل بكامل طاقته وهناك طابور (Queue) مهام بحجم معالج كامل تنتظر دورها!
- في سيرفر رباعي النواة (4 Cores): الرقم 1.0 يعني أن 25% من قدرة المعالجة مستخدمة. للوصول لـ 100%، يجب أن يكون الـ Load Average هو 4.0.
قاعدة ذهبية: إذا كان الـ Load Average أعلى من عدد أنوية المعالج (Cores) في سيرفرك لفترة طويلة (أكثر من 5 دقائق)، فهذا يعني أن سيرفرك يعاني من اختناق (Bottleneck)، والطلبات بدأت تتأخر.
الغوص العميق باستخدام htop و glances
الأمر top التقليدي جيد، لكن htop أفضل بكثير. يقدم واجهة رسومية، ويدعم التمرير، وقتل العمليات بسهولة. لكن إذا أردت مراقبة كل شيء (CPU, RAM, Disk I/O, Network) في شاشة واحدة، فقم بتنصيب glances:
sudo apt install htop glances -y
glances
في شاشة glances، إذا لاحظت أن قسم IOWait (وقت الانتظار لعمليات الإدخال والإخراج) مرتفع، فهذا يعني أن مشكلتك ليست في المعالج، بل في سرعة استجابة القرص الصلب (Hard Disk) للطلبات! (ربما تحتاج للترقية إلى SSD أو NVMe).
تحليل اختناقات القرص باستخدام iotop
إذا كان الـ IOWait مرتفعاً، يجب أن نعرف من هو البرنامج الذي يستهلك القرص. هنا يأتي دور iotop:
sudo apt install iotop -y
sudo iotop -o
الخيار -o يعرض فقط العمليات التي تقوم بالكتابة والقراءة حالياً. قد تكتشف أن قاعدة البيانات (MySQL) أو مهمة النسخ الاحتياطي (rsync) هي التي تشل حركة السيرفر.
أداة sysstat وتاريخ الأداء (Historical Data)
الأدوات السابقة تعرض الحالة "الآن". لكن ماذا لو اشتكى العملاء من بطء السيرفر الساعة 3 فجراً؟ كيف ستعرف ما حدث؟
الحل هو حزمة sysstat التي تحتوي على أداة sar:
sudo apt install sysstat -y
sudo systemctl enable sysstat
sudo systemctl start sysstat
تأكد من تفعيل جمع البيانات بفتح /etc/default/sysstat وتغيير ENABLED="true". بعد ذلك، يمكنك معرفة حالة المعالج الساعة 3 فجراً عن طريق:
sar -u -s 03:00:00 -e 04:00:00
أو معرفة استهلاك الذاكرة العشوائية (RAM) في نفس الوقت:
sar -r -s 03:00:00 -e 04:00:00
مع هذه الأدوات، لن تخمن أبداً سبب بطء السيرفر؛ بل ستعرف المشكلة بدقة علمية قاطعة، سواء كانت Memory Leak، أو CPU Spike، أو Disk I/O Bottleneck.
تعمق أكثر: فهم استهلاك الذاكرة العشوائية (RAM) في لينكس
الكثير من المبتدئين يصابون بالذعر عندما يكتبون الأمر free -m ويرون أن الذاكرة "ممتلئة بالكامل". لكن في نظام لينكس، المقولة الشهيرة هي: "الذاكرة غير المستخدمة هي ذاكرة مهدرة" (Unused RAM is wasted RAM). النواة تقوم باستخدام أي مساحة غير مستغلة كـ (Cache / Buffers) لتسريع قراءة الملفات التي يتم الوصول إليها بشكل متكرر. إذا احتاج تطبيقك (مثل Nginx أو PHP) لذاكرة، ستقوم النواة فوراً بتفريغ الكاش وإعطائها للتطبيق. لذلك، الرقم الذي يجب أن تقلق بشأنه ليس "used" بل "available".
متى تبدأ المشاكل؟ (Swapping)
تحدث الكارثة الحقيقية للأداء عندما تنفد الذاكرة الفعلية وتضطر النواة لاستخدام الـ Swap (جزء من القرص الصلب يستخدم كذاكرة وهمية). القرص الصلب أبطأ بآلاف المرات من الـ RAM. إذا لاحظت باستخدام htop أن الـ Swap بدأ يمتلئ، وأن السيرفر أصبح بطيئاً جداً، فأنت تواجه ظاهرة تسمى (Thrashing). الحلول المقترحة هي:
- تحسين كود التطبيق لتقليل استهلاك الذاكرة.
- تعديل إعدادات
php-fpm(تحديدpm.max_childrenبرقم يتناسب مع حجم الذاكرة). - ترقية السيرفر وزيادة حجم الذاكرة العشوائية (Vertical Scaling).
أدوات التشخيص المتقدمة جداً: perf و strace
إذا كنت مبرمجاً محترفاً (C++ أو Go أو Rust) وتواجه بطئاً غير مبرر في تطبيقك، فأنت بحاجة للنظر داخل البرنامج أثناء عمله. أداة strace تقوم بتسجيل كل نداء نظام (System Call) يقوم به البرنامج.
# تتبع تطبيق بناءً على رقم العملية (PID)
strace -p 1234 -c
هذا سيعطيك تقريراً عن أكثر نداءات النظام التي تستهلك الوقت. قد تكتشف أن تطبيقك يفتح ويغلق ملفاً آلاف المرات في الثانية بشكل غير مبرر!
💬 التعليقات
0 تعليقات