Skip to content
VDS · حل المشكلات

CPU عند 100%

كيف تجد العملية التي تستهلك أنوية CPU، وتميّز الحمل الحقيقي من انتظار القرص، وتقرر هل تصلح الشفرة أم تنتقل إلى مستوى أعلى.

آخر تحديث 23 أغسطس 2026

إن استقرار الرسم البياني لوحدة المعالجة المركزية (CPU) عند مستوى ثابت في علامة التبويب «نظرة عامة» ليس حالة طارئة بحد ذاته: فبناء مشروع أو إنشاء أرشيف سيستخدم بصدق جميع الأنوية ثم يحررها. لكن الأمر مقلق عندما يستمر هذا الثبات لساعات ويتوقف الجهاز عن الاستجابة. لنتعرف على السبب.

الخطوة 1. تحقق مما يستهلك الموارد

علامة التبويب «الشاشة» (VNC) مناسبة للعمل مع البرامج ملء الشاشة:

btop
htop

لا تنقل وحدة التحكم التسلسلية حجم النافذة؛ فهي دائمًا 80×24 هناك، لذا ستُقطع الواجهة. بالنسبة لوحدة تحكم نصية، استخدم الأوامر القياسية:

top -b -n1 | head -20
ps aux --sort=-%cpu | head -10

تذكّر الحساب: يُحسب %CPU لكل نواة. تعني 400% على VDS-3 جميع الأنوية الأربع، بينما 100% على VDS-4 تعني نواة واحدة فقط من أصل ست.

الخطوة 2. ميّز وحدة المعالجة المركزية عن القرص

يرتفع متوسط الحمل (load average) أيضًا بسبب انتظار الإدخال/الإخراج، وليس بسبب الحساب فقط:

uptime
vmstat 1 5

في مخرجات vmstat، انظر إلى الأعمدة us (كود المستخدم)، وsy (النواة)، وwa (انتظار القرص)، وst (الوقت المسروق). تعني قيمة wa الكبيرة أن وحدة المعالجة المركزية خاملة في انتظار القرص — فعنق الزجاجة هو سرعة الكتابة، وليس الحساب. يُحدَّد ثبات القرص في مستوياتنا بقاعدة: كتابة 60 MB/s لكل نواة، بما لا يقل عن 60 ولا يزيد عن 400 MB/s، والقراءة ضعف ذلك، ودفعة تفوق الثبات بثلاثة أضعاف تستمر 30 ثانية. إذا كانت إحدى المهام تكتب باستمرار، فستنتهي الدفعة وستصل إلى الثبات.

الخطوة 3. افحص عملية محددة

pidstat -p <pid> 1 5
cat /proc/<pid>/status
journalctl -u <service> -n 100 --no-pager

النتائج الشائعة:

  • تطبيق ويب يدور في حلقة لا نهائية بعد طلب فاشل؛
  • قاعدة البيانات تنفذ استعلامًا بدون فهرس — تحقق من سجل الاستعلامات البطيئة الخاص بها؛
  • مهمة cron تبدأ أكثر مما تستطيع إنهاءه، وتتراكم النسخ: سيعرض ps aux | grep <name> عشرات النسخ؛
  • برنامج تعدين وصل إلى الجهاز عبر كلمة مرور root ضعيفة. العلامة هي عملية باسم بلا معنى تعمل تحت مستخدم غير قياسي مع نطاق ترددي صادر مرتفع. في هذه الحالة، إعادة تثبيت الجهاز من علامة التبويب «الوصول» أسهل من تنظيفه.

الخطوة 4. حدّد، لا تقتل

إذا كانت العملية ضرورية لكن يجب ألا تعطّل الباقي:

renice -n 15 -p <pid>
systemctl set-property myapp.service CPUQuota=200%

CPUQuota=200% تعني نواتين كاملتين. يبقى حد systemd بعد إعادة تشغيل الخدمة؛ أما renice فلا.

قبل قتل عملية باستخدام kill -9، جرّب systemctl stop العادي. القتل القسري لقاعدة بيانات يكلفك ملفات تالفة واستعادة طويلة عند التشغيل التالي.

عندما لا يكون السبب في الكود

إذا كان الحمل مشروعًا وثابتًا، فمعالج Ryzen 9 7950X يقوم بعمله — ببساطة لا توجد أنوية كافية للمهمة. لا يمكن تغيير المستوى إلا صعودًا، مع دفع إضافي عن الأيام المتبقية من الفترة المدفوعة: راجع مقالة ترقية خطتك ودفع الفرق. التخفيض مرة أخرى غير متاح، لذا تأكد أولًا من الرسوم البيانية الأسبوعية والشهرية أن الثبات ليس حالة عارضة.