كيف تحدد ما إذا كان الاختناق ناجماً عن وحدة المعالجة المركزية أو الذاكرة أو الإدخال/الإخراج أو الشبكة؟

Question

Accepted Answer

**انظر إلى استخدام الموارد والتشبع، ثم أكد ذلك بالقياس.** يوفر نهج منظم — **طريقة USE** (Utilization, Saturation, Errors) — فحصاً لكل مورد حتى لا تلوم المورد الخاطئ.

## طريقة USE

لكل مورد (CPU، الذاكرة، القرص، الشبكة)، اسأل ثلاثة أشياء:

```text
UTILIZATION → how busy is it (% time in use)?
SATURATION  → how much queued/waiting work (load, run queue, swap)?
ERRORS      → any errors (dropped packets, disk errors, OOM kills)?
→ a resource that is saturated, not just busy, is usually the bottleneck.
```

## الأدوات والأعراض لكل مورد

لكل مورد توقيع مميز يمكنك قراءته باستخدام الأدوات القياسية:

```text
CPU     → top/htop: high %us or load > #cores, run queue backed up
MEMORY  → free/vmstat: low free RAM + high SWAP in/out (si/so) → swapping = thrashing
DISK I/O→ iostat/vmstat: high %iowait, %util ~100%, high await → I/O-bound
NETWORK → iftop/sar/ss: bandwidth saturated, retransmits, high latency
```

التمييزات الرئيسية: **الحمل المرتفع مع %us مرتفعة** يعني ارتباط بوحدة المعالجة؛ **swapping (si/so)** يعني ضغط الذاكرة؛ **%iowait مرتفعة** يعني أن وحدة المعالجة المركزية خاملة *في انتظار القرص*؛ **latency/retransmits** مرتفعة تشير إلى الشبكة.

```text
$ vmstat 1
 r  b   swpd  free   si  so   bi   bo  us sy id wa
 8  0      0  120m   0   0   12   20  92  6  2  0   ← CPU-bound (id=0, wa=0)
 1  3 800m   30m  40 120  900    8   5  3  2 90   ← I/O + swap (wa=90, so>0)
```

## أكد بالقياس

لا تتوقف عند رقم واحد. **قم بتحليل الملف الشخصي** للعملية (مثل `perf`، أداة تحليل CPU/heap) للعثور على الدالة الساخنة أو التخصيص، غيّر شيئاً واحداً، و**أعد القياس**. قد تكون الأعراض مضللة — قد تكون وحدة المعالجة المركزية المرتفعة في الواقع انتظاراً نشطاً ناجماً عن نزاع القفل، وليس عملاً حقيقياً.

## لماذا يهم

إصلاح المورد الخاطئ (إضافة RAM إلى صندوق مرتبط بوحدة المعالجة) يهدر المال ولا يساعد. طريقة USE بالإضافة إلى الأداة الصحيحة تعزل القيد الفعلي بسرعة، وإعادة القياس تؤكد أن الإصلاح غيّر الوضع.