🔝 الدليل الرئيسي: أساسيات Linux 2026
كل ما يُنفَّذ على خادم Linux هو عملية. فهم كيف تولد، تعيش، تتواصل وتموت من أكبر مكاسب الإنتاجية لمسؤول أو مطوّر. عندما يبطؤ VPS الساعة 22، عندما تستجيب API بـ latency 8 ثوانٍ، عندما يُعلن journal أن « عملية قُتلت »، السبب دائمًا في سلوك عملية محددة. يُعطيك هذا الدرس المفردات والأدوات لمراقبة وتقييد وإنهاء أي عملية بنظافة، في 8 خطوات.
المتطلبات
- Linux وحساب بوصول sudo
- معرفة أساسية بسطر الأوامر
- أساسيات systemd مُوصى بها لكن غير إلزامية
- المستوى: متوسط مبتدئ
- الوقت المُقدَّر: 80 دقيقة
الخطوة 1 — المفردات الأساسية
كل عملية لها معرّف صحيح فريد يُسمى PID (Process IDentifier)، مُعطى من النواة لحظة الإنشاء. PID 1 خاص: هو أول عملية أطلقتها النواة وسلف كل الأخريات. على Linux حديث، systemd يحتل هذا PID 1. عندما تُطلق عملية أخرى (عبر fork() ثم execve())، الثانية تصبح ابنتها وترث بيئتها، مجلدها الحالي، مستخدمها وفئتها الفعّالة.
ثلاث مفاهيم أخرى تستحق المعرفة فورًا. المستخدم الفعّال (EUID) يُحدّد أي صلاحيات تستخدم العملية. هرمية cgroups، آلية نواة Linux التي تُجمّع العمليات لتطبيق حدود موارد، هي قلب systemd والحاويات الحديثة. الإشارات رسائل قصيرة ترسلها النواة للعمليات لتطلب إنهاءها أو تجميدها أو إعادة تشغيلها.
الخطوة 2 — سرد العمليات بـ ps
ps -ef # tous les processus, format complet
ps auxf # tous, avec %CPU/%MEM, en arborescence
ps -eo pid,user,%cpu,%mem,command --sort=-%mem | head -20 # top 20 par RAMمخرج ps -ef يسرد لكل عملية: مستخدمها، PID، PID parent (PPID)، وقت البدء والأمر الكامل. ps auxf يتتبّع شجرة الأب-الابن بانحناء بصري. ps -eo يُتيح تخصيص الأعمدة. احفظ خاصة ps -eo pid,user,%cpu,%mem,command --sort=-%cpu الذي يُشير فورًا إلى العملية الأكثر شراهة CPU.
الخطوة 3 — الرصد في الزمن الحقيقي بـ top وhtop وbtop
top # par défaut, trié par %CPU
top -o %MEM # trié par %MEM
htop # version améliorée
btop # version graphique ASCIIفي htop، بضع مفاتيح تُحرّر إنتاجية كبيرة: F2 يفتح التفضيلات، F3 فلتر بالاسم، F4 بحث، F5 يُبدّل لشجرة، F6 يُغيّر عمود الترتيب، F9 يُرسل إشارة للعملية، F10 ينهي. السطر الأعلى يعرض متوسط الحمل على 1، 5، 15 دقيقة. حمل أعلى من عدد أنوية CPU خلال 15 دقيقة يُشير لتشبّع مستدام.
الخطوة 4 — فهم الحالات والموارد
عمود S (state) في ps أو top يُعطي الحالة في T. خمس حالات تستحق المعرفة: R (Running)، S (Sleeping، الأكثر شيوعًا)، D (Disk sleep، محجوب على عملية قرص غير قابلة للمقاطعة)، Z (Zombie)، T (sTopped، مُعلَّق بـ SIGSTOP).
العمليات في حالة D من أكثر المؤشرات معبّرة عن مشكلة أداء: إذا ركدت عدة عمليات في D، فالقرص أو نظام الملفات مُشبَع. iostat -xz 1 من حزمة sysstat يُؤكّد بأعمدة r/s وw/s وخاصة %util. فوق 80% استخدام مُستدام، قرص يصبح bottleneck. عمليات zombies نادرًا ما تكون مشكلة في حد ذاتها لكن تراكمها يكشف parent لا يُجري wait() بشكل صحيح.
الخطوة 5 — إرسال إشارات بـ kill
تحت Linux، لا نوقف عملية، نطلب منها التوقّف. الطلب يأخذ شكل إشارة.
kill PID # SIGTERM par défaut, demande poliment
kill -9 PID # SIGKILL, coupe net (le noyau)
kill -SIGHUP PID # SIGHUP, demande au démon de relire sa config
kill -l # liste les signaux supportés
pkill nom # cherche par nom et envoie SIGTERM
pkill -9 -f "node.*server.js" # cherche par ligne de commande complète
killall -SIGTERM nginx # tue tous les processus du nom donnéالقاعدة الذهبية: ابدأ بـ SIGTERM، انتظر بضع ثوانٍ، اصعد لـ SIGKILL فقط عند الضرورة. SIGTERM (15) يطلب بأدب؛ الكود التطبيقي له إمكانية إغلاق ملفاته. SIGKILL (9) يُعالَج مباشرة من النواة دون حتى أن تتكلّم العملية — مكافئ نزع القابس. إذا قتلت منهجيًا بـ -9، تُفسد عاجلًا قاعدة SQLite، ملفًا قيد الكتابة، أو حالة تطبيقية. SIGHUP (1) يخدم تاريخيًا لطلب من démon طويل العمل (Nginx، sshd، postfix) إعادة قراءة تهيئته دون إعادة تشغيل.
الخطوة 6 — OOM Killer وحدود الذاكرة
عندما يقترب RAM الحرة من الصفر وSwap لا يكفي، نواة Linux تُفعّل OOM Killer (Out-Of-Memory Killer)، آلية تختار عملية وتقتلها بقسوة (مكافئ SIGKILL). هذا الحدث متكرر على VPS متواضعة سيئة الإعداد، ومُربك خاصة لأنه يحدث دون إنذار تطبيقي.
# Voir si l'OOM Killer a frappé récemment
journalctl -k -b | grep -i "out of memory\|killed process"
dmesg | grep -i "Killed process"
# Voir le score OOM d'un processus (plus haut = plus susceptible d'être tué)
cat /proc/PID/oom_score
cat /proc/PID/oom_score_adj # ajustement, entre -1000 (immunisé) et +1000
# Limiter explicitement un service via systemd
sudo systemctl edit mon-app
# [Service]
# MemoryMax=512M
# MemoryHigh=400Mالـ oom_score يُحسَب من النواة. عملية تريد حمايتها (sshd للحفاظ على الوصول) تستطيع استلام oom_score_adj=-1000، مما يُحصّنها. عكسيًا، خدمة cache يمكن إعادة تشغيلها بسهولة قد تتلقّى +500. هذه التعديلات تعيش في ملفات unit systemd عبر OOMScoreAdjust=-100. الدفاع الأفضل: ضبط حدود MemoryMax على الخدمات التطبيقية.
الخطوة 7 — منهجية USE للتشخيص
Brendan Gregg، مهندس أداء شهير، روّج منذ 2012 لـ USE method (Utilization, Saturation, Errors). لكل مورد (CPU، ذاكرة، قرص، شبكة)، نقيس 3 أشياء: معدّل استخدامه، تشبّعه (file d’attente)، عدد الأخطاء.
# CPU
uptime # charge moyenne 1/5/15 min
mpstat -P ALL 1 # par cœur (paquet sysstat)
vmstat 1 # colonnes r (run queue), us, sy, id, wa
# Mémoire
free -h # libre/utilisée/cache
vmstat 1 # colonnes si/so (swap in/out, doit rester à 0)
# Disque
iostat -xz 1 # %util, await, rrqm/s, wrqm/s
df -h # remplissage des partitions
df -i # inodes (saturation invisible sinon)
# Réseau
ss -s # statistiques sockets
ip -s link show eth0 # paquets, erreurs, dropsسلسلة التشخيص تتبع نفس المنطق: نقيس أولًا الاستخدام، ثم التشبّع، ثم الأخطاء، ونعود للسبب. حمل 8 على خادم 4 أنوية مع %iowait عند 70% في vmstat و%util عند 100% في iostat يحكي قصة واضحة: النظام ينتظر القرص. هذا الانضباط أكثر موثوقية من dashboards الرصد التي تُجمّع وتُخفي الذروات.
الخطوة 8 — التحقق والعادات الجيدة
# 1. Vue panoramique
uptime
free -h
df -h /
# 2. Top consommateurs
ps -eo pid,user,%cpu,%mem,command --sort=-%cpu | head -10
ps -eo pid,user,%cpu,%mem,command --sort=-%mem | head -10
# 3. Saturation disque ?
vmstat 1 5
iostat -xz 1 5
# 4. États suspects (D, Z)
ps -eo pid,user,stat,command | awk '\$3 ~ /^[DZ]/'
# 5. OOM récents
journalctl -k -b | grep -iE "oom|killed process" | tail -10
echo "✓ diagnostic terminé"على خادم سليم، ترى حملًا مُوافقًا لعدد الأنوية أو أقل، RAM مُستخدمة لكن بـ cache، قرصًا تحت 80%، لا عملية في D مستمرة، لا zombie متراكم، لا أثر OOM حديث. أي انحراف عن هذا المعيار مسار للحفر. عادة تشغيل هذا الروتين في أقل من 60 ثانية تُميّز تصحيحًا بضع دقائق عن بحث أعمى لساعات.
أخطاء شائعة
| الخطأ | السبب | الحل |
|---|---|---|
| « No such process » على kill | PID غير موجود أو منتهٍ | أعد السرد بـ ps aux | grep |
| kill SIGTERM بلا أثر | العملية تتجاهل الإشارة أو في D | شخّص بـ strace -p PID، استخدم SIGKILL كملاذ أخير |
| Zombie مستمر | parent لا يفعل wait() |
اقتل parent؛ PID 1 سيتبنّى ويُنظّف |
| حمل عالٍ بدون CPU مُشبَع | عمليات في D محجوبة على القرص | iostat -xz 1 |
| OOM Killer متكرر | تسرّب ذاكرة تطبيقي أو حد منخفض | أضف MemoryMax systemd |
| htop غير مُثبَّت | الحزمة غائبة | sudo apt install htop أو sudo dnf install htop |
الأسئلة الشائعة
ما الفرق بين kill وkillall وpkill؟kill PID يُرسل إشارة لـ PID محدد. killall nom يُرسل لكل العمليات التي أمرها بالضبط nom. pkill أقوى: يقبل تعبيرات، يُمكن الفلترة بالمستخدم، الأب، مدة التنفيذ، وخياره -f يطابق سطر الأمر الكامل. للاستخدام اليومي، pkill -f motif الأكثر تعدد استخدام.
كيف نُطلق عملية في الخلفية تنجو من الانفصال؟
ثلاث خيارات. nohup commande & يفصل العملية من terminal. tmux أو screen يفتحان جلسة دائمة. لخدمة دائمة، اكتب ملف unit systemd — الحل النظيف الذي ينجو من reboots ويستفيد من journalisation.
كيف نعرف الملفات التي فتحتها عملية؟lsof -p PID يسرد file descriptors المفتوحة. هذا الأمر يكشف غالبًا ما تفعله عملية حقًا — مثلًا Nginx يحتجز ملف log محذوف يمنعه من التحرير فعليًا (حالة كلاسيكية « du يقول X، df يقول Y »).
كيف نُقَيِّد CPU عملية دون systemd؟nice يضبط أولوية عملية (-20 الأكثر أولوية، +19 الأقل). cpulimit يُحدّد صراحةً نسبة CPU. chrt يتلاعب بفئة scheduling للزمن الحقيقي اللين. في 2026، الطريق النظيف يمرّ بـ cgroups v2 وsystemd.
كيف نرى تاريخ استخدام CPU لعملية؟
top وhtop فوريين. لتتبّع تاريخي، حزمة sysstat مع démon sadc تجمع كل 10 دقائق، وsar يُعيد التشغيل. pidstat 1 يُحدِّث كل ثانية ويكتب القيم لكل PID.
عمليتي تستهلك 100% CPU، كيف أعرف أين تعلق؟
أربع أدوات. strace -p PID -c لـ 10 ثوانٍ يعرض ملخّص syscalls. perf top -p PID يُحلّل في الزمن الحقيقي. py-spy (Python) أو node --prof يُحلّلان على مستوى لغة. أخيرًا، flamegraph مُولَّد بـ perf record + FlameGraph يُعطي التصوّر النهائي.