إدارة أنظمة لينكس

تحليل الأداء واستكشاف الأعطال

18 دقيقة الدرس 5 من 28

تحليل الأداء واستكشاف الأعطال

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

متوسط الحمل: ماذا يعني فعلًا؟

متوسط الحمل هو الرقم الأكثر سوء قراءة بين المهندسين. يظهر في مخرجات uptime وtop وhtop على شكل ثلاثة قيم: المتوسطات المتحركة الموزونة أسيًّا لمدة دقيقة واحدة وخمس دقائق وخمس عشرة دقيقة لطول طابور التشغيل — وهو عدد العمليات التي إما تعمل على المعالج أو تنتظر في حالة نوم لا يمكن مقاطعتها (انتظار قرص، أقفال نواة).

الفهم الجوهري: متوسط الحمل ليس معدل استخدام المعالج. آلة بأربعة أنوية معالجة ومتوسط حمل 4.0 مشبعة تمامًا — كل نواة لديها عملية واحدة تشغّلها ولا شيء ينتظر. الآلة نفسها بحمل 8.0 لديها في المتوسط 4 عمليات تنتظر المعالج في كل لحظة. على آلة بـ32 نواة، الحمل 8.0 هامش مريح.

قاعدة عملية: اقسم متوسط الحمل على عدد أنوية المعالج (nproc أو lscpu | grep "^CPU(s)"). النسبة فوق 1.0 تعني تشبّعًا؛ فوق 2.0 تعني تنافسًا شديدًا. نسبة قريبة من الصفر مع أوقات استجابة عالية تشير إلى انتظار الإدخال/الإخراج لا المعالج.

# قراءة متوسط الحمل وعدد الأنوية دفعة واحدة
uptime
nproc

# لقطة 5 ثوانٍ لاستخدام كل نواة معالج (يتطلب sysstat)
mpstat -P ALL 5 1

# عمود انتظار الإدخال/الإخراج (wa) في iostat — iowait عالٍ + CPU منخفض = اختناق تخزين
iostat -xz 5 1

منهجية التشخيص السريع للأداء

أرسى المهندس Brendan Gregg من Netflix طريقة USE Method: لكل مورد (معالج، ذاكرة، أقراص، شبكة، أنظمة ملفات)، قِس الاستخدام والتشبع والأخطاء. التطبيق من الأعلى إلى الأسفل يُلغي التخمين:

المعالج — top / mpstat — تحقق من %user و%sys و%iowait و%steal (على الأجهزة الافتراضية)
الذاكرة — free -h / vmstat 1 — راقب أعمدة swap si/so؛ أي قيمة غير صفرية تعني تشبعًا
إدخال/إخراج التخزين — iostat -xz 5 — %util قريب من 100% وawait مرتفع (مللي ثانية) يُثبتان تشبع القرص
الشبكة — ss -s / sar -n DEV 1 — عدد الاتصالات، إعادة الإرسال، أخطاء الواجهة
العمليات — ps aux --sort=-%cpu، pidstat 1 — تحديد العملية المسببة للمشكلة

تدفق التشخيص السريع لأداء Linux: ابدأ من متوسط الحمل، تفرّع إلى المعالج أو الذاكرة أو الإدخال/الإخراج، ثم حدّد العملية المسببة.

إيجاد نقاط الاختناق باستخدام vmstat وiostat

vmstat 1 هو مرقاب ضربات قلب نظامك — شغّله 10 ثوانٍ وراقب الأعمدة. عمود r (طابور التشغيل) يعكس متوسط الحمل لحظيًّا. عمود b يُظهر العمليات في نوم لا يمكن مقاطعتها — هذه تقريبًا دائمًا عالقة في انتظار الإدخال/الإخراج. أعمدة الصفحة الافتراضية si/so يجب أن تكون صفرًا؛ أي قيمة غير صفرية تعني أن النواة تتبادل الصفحات بشكل محموم.

# vmstat: r=قابل للتشغيل، b=محجوب، si/so=تبادل الصفحات، us/sy/wa/id=نسبة CPU
vmstat 1 10

# iostat موسّع: util%، await(ms)، r/s w/s — جهاز واحد في كل سطر
# -x = موسّع, -z = تجاهل الأجهزة الخاملة, 5 = الفترة الزمنية, 3 = العدد
iostat -xz 5 3

# ما العمليات التي تُجري عمليات قرص الآن؟
iotop -o -b -n 3

# أخذ عينات CPU/ذاكرة لكل عملية (مثل top لكن قابل للبرمجة)
pidstat -u -r -d 2 5

في بيئات الإنتاج الكبرى: هذه الأدوات اللحظية للتشخيص الفوري. بعد استقرار الحادثة، يجب أن يأتي التحليل الاسترجاعي من مقاييس السلاسل الزمنية (Prometheus + Grafana، Datadog، CloudWatch). الأدوات في سطر الأوامر تُجيب على "ما الذي يحدث الآن"؛ منظومة المراقبة تُجيب على "متى بدأ هذا وكم مرة يحدث".

strace: تتبع استدعاءات النظام

يعترض strace كل استدعاء نظام تُجريه عملية — open()، read()، write()، connect()، futex(). هكذا تشخّص عملية عالقة تستهلك المعالج دون فائدة، أو عملية تدور في حلقة على استدعاء stat() فاشل.

تحذير في الإنتاج: يُضيف strace عبئًا بنسبة 10-30% عبر ptrace الذي يُسلسل استدعاءات النظام. لا تُرفقه أبدًا بعملية عالية الإنتاجية على خادم مُشبَع دون فهم هذه التكلفة. يُفضَّل الإرفاق بنسخة واحدة فقط، أو استخدام strace -c (ملخص فقط) لتحميل أخف.

# إرفاق strace بـ PID قيد التشغيل (-p)، إظهار الطوابع الزمنية (-t)، تتبع العمليات الفرعية (-f)
strace -p 12345 -tt -f 2>&1 | head -50

# وضع الملخص: عد الاستدعاءات + الوقت المنقضي — أثر خفيف، رائع للتحليل
strace -c -p 12345

# تتبع استدعاءات محددة فقط (فتح الملفات والاتصالات الشبكية)
strace -e trace=openat,connect -p 12345

# تتبع أمر جديد وحفظ المخرجات الكاملة في ملف
strace -o /tmp/trace.txt -tt nginx -t

اكتشافات نموذجية من strace: عملية تستدعي stat() مرارًا على ملف إعداد مفقود (خطأ في الإعداد)؛ عملية عالقة في futex(FUTEX_WAIT) إلى الأبد (توقف تام على كائن إقفال)؛ مئات استدعاءات connect() تعود جميعها بـECONNREFUSED (خدمة تابعة معطلة).

lsof: الملفات المفتوحة ومواصفات الملفات

في Linux، كل شيء ملف: المقابس، الأنابيب، عقد الأجهزة، الملفات الفعلية. يكشف lsof (قائمة الملفات المفتوحة) ما تمتلكه العملية مفتوحًا. هذا ضروري عند تشخيص أخطاء "Too many open files"، أو إيجاد العملية التي تحمل ملفًا محذوفًا (يمنع استرداد مساحة القرص)، أو اكتشاف العملية المتصلة بعنوان IP بعيد.

# جميع الملفات المفتوحة لـ PID معين
lsof -p 12345

# إظهار الاتصالات الشبكية فقط لـ PID
lsof -p 12345 -i

# أي عملية تفتح هذا المنفذ؟
lsof -i :8080

# إيجاد من يحتجز ملفًا محذوفًا لكنه لا يزال مفتوحًا (لن يُستعاد القرص حتى يُغلق)
lsof +L1

# عد مواصفات الملفات المفتوحة لكل عملية — اكتشف المرشحين لتسرب FD
lsof | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

تجميع كل شيء: سيناريو تشخيص واقعي

قفز متوسط الحمل من 1.2 إلى 14 على خادم بـ8 أنوية. إليك النهج المنهجي:

نفّذ uptime — تأكد من أن 14/8 = 1.75× تشبّع.
نفّذ vmstat 1 — r=10، b=4، wa=60%. تأكّد ارتفاع انتظار الإدخال/الإخراج.
نفّذ iostat -xz 1 — /dev/sda عند 99% استخدام، await=420ms. القرص هو نقطة الاختناق.
نفّذ iotop -o — mysqld يكتب بمعدل 180 MB/s.
نفّذ strace -c -p <PID mysqld> لمدة 5 ثوانٍ — 90% من الوقت في write().
نفّذ lsof -p <PID mysqld> -i — 3,200 اتصال عميل. مجمع الاتصالات مستنفذ، العملاء ينتظرون.
السبب الجذري: مهمة دفعية منفلتة فتحت آلاف الاتصالات، كلها تُجري عمليات كتابة ضخمة. الحل: أوقف مهمة الدفعة، قيّد مجمع الاتصالات، أضف تحليل الاستعلامات البطيئة.

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