العثور على السكربتات التي تستهلك المعالج والذاكرة باستخدام أمر htop في خادم لينكس

أمر htop في خادم لينكس هو واحد من أكثر أدوات المراقبة العملية المستخدمة للعثور على السكربتات التي تستهلك المعالج والذاكرة بشكل مفرط في الوقت الحقيقي. يمكنك من خلال شاشة htop مراجعة أعمدة CPU% و MEM% و PID و USER و TIME+ و COMMAND لمعرفة أي من العمليات مثل PHP أو Python أو Node.js أو cron أو قاعدة البيانات أو العمليات النظامية تجهد الخادم؛ يمكنك بعد ذلك التحقق من مالك العملية، ومسار الملف، والغرض من التشغيل للتدخل بشكل آمن.

سواء كنت تستخدم استضافة مشتركة أو VPS أو VDS أو خادم مخصص، فإن جزءًا كبيرًا من التباطؤ المفاجئ ينشأ عن السكربتات التي تعمل دون رقابة. على سبيل المثال، يمكن أن يؤدي مكون إضافي خاطئ في ووردبريس، أو ملف PHP يدخل في حلقة لانهائية، أو مهمة cron تعمل بكثافة، أو استعلام قاعدة بيانات غير مُحسّن أو ملف ويب تم اختراقه إلى زيادة استخدام المعالج إلى 100% في دقائق. عندما تزداد استهلاك الذاكرة، قد تتعطل الخدمات، وتنخفض اتصالات MySQL، وتظهر المواقع الإلكترونية خطأ 503، أو قد يقوم نواة لينكس بإنهاء بعض العمليات باستخدام OOM Killer.

في هذا الدليل، سنغطي خطوة بخطوة كيفية تثبيت htop، وكيفية قراءة الشاشة، وكيفية تمييز السكربتات التي تستهلك المعالج والذاكرة، وكيفية العثور على مسار الملف من خلال PID، وكيفية التدخل بأمان في العملية. بالإضافة إلى ذلك، سنناقش الشكوك الأمنية، والتحقق من cron، وتحليل السجلات، وتقديم اقتراحات تحسين قابلة للتطبيق لمنع حدوث نفس المشكلة مرة أخرى. إذا كنت تواجه مشكلة في حدود الموارد بشكل متكرر، يمكنك مراجعة حزم خوادم VPS و استضافة ويب عالية الأداء لتحسين اختيار البنية التحتية.

ما هو htop ولماذا هو أكثر فائدة من أمر top؟

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

يمكنك رؤية المعلومات التالية في الوقت الفعلي باستخدام htop:

• نسبة استخدام المعالج لكل عملية
• نسبة استخدام الذاكرة ومقدار الذاكرة المستخدمة لكل عملية
• رقم PID للعملية
• المستخدم الذي يشغل العملية
• اسم الأمر أو السكربت
• مدة التشغيل وقيمة الأولوية
• متوسط التحميل، إجمالي الذاكرة، استخدام الذاكرة الافتراضية، واستخدام نوى المعالج

خاصة في بيئة استضافة حيث تعمل عدة مواقع أو مستخدمين أو خدمات على نفس الخادم، فإن رؤية إجمالي استخدام الموارد فقط ليست كافية. يجب تحديد المستخدم أو الموقع أو مهمة cron أو ملف السكربت الذي ينتمي إليه المشكلة. يوفر أمر htop في خادم لينكس تشخيصًا أوليًا سريعًا في هذه النقطة.

تثبيت htop: الأوامر حسب التوزيعة

قد لا يأتي htop مثبتًا مسبقًا في العديد من توزيعات لينكس الحديثة. إذا كان لديك صلاحيات root أو sudo، يمكنك تثبيته في ثوانٍ. من الأفضل تحديث قائمة الحزم قبل التثبيت، خاصة في الخوادم التي تم إعدادها حديثًا، لتقليل احتمالية حدوث أخطاء.

تثبيت htop على خوادم Ubuntu و Debian

يمكن استخدام الأوامر التالية على خادم يعتمد على Ubuntu أو Debian:

sudo apt update

sudo apt install htop -y

بعد التثبيت، يمكنك بدء الأداة بكتابة الأمر htop. إذا لم يكن لديك صلاحيات sudo، قد تحتاج إلى طلب الدعم من مزود الاستضافة الخاص بك. عادةً ما يكون الوصول إلى root متاحًا لك إذا كنت تستخدم VPS قابل للإدارة.

تثبيت AlmaLinux و Rocky Linux و CentOS و RHEL

في الأنظمة المعتمدة على RHEL، قد يكون مدير الحزم dnf أو yum حسب الإصدار:

sudo dnf install htop -y

في إصدارات CentOS القديمة، قد تحتاج إلى مستودع EPEL:

sudo yum install epel-release -y

sudo yum install htop -y

إذا تم التثبيت بنجاح، ستظهر شاشة المراقبة الملونة عند كتابة htop في الطرفية. إذا كنت مبتدئًا في إدارة الخوادم، يمكنك أيضًا مراجعة دليل أوامر لينكس كخطوة بداية عملية.

قراءة شاشة htop: ماذا تعني كل عمود؟

عند فتح htop، ستجد في الجزء العلوي معلومات حول نوى المعالج، والذاكرة، والذاكرة الافتراضية، وعدد المهام، وعدد الخيوط، ومتوسط التحميل، ومعلومات فترة التشغيل. في الجزء السفلي، يتم سرد العمليات النشطة. المجالات الأكثر استخدامًا في تشخيص المشاكل هي كما يلي.

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

العثور على السكربتات التي تستهلك المعالج باستخدام htop

للعثور على السكربتات التي تستخدم المعالج بشكل مفرط، يمكنك اختيار مجال الترتيب بالضغط على مفتاح F6 أو الترتيب حسب عمود CPU% أثناء تشغيل htop. في بعض الطرفيات، إذا كان دعم الفأرة مفعلًا، يكفي النقر على عنوان CPU%. العمليات التي تظهر في أعلى الشاشة هي تلك التي تستهلك المعالج بأعلى نسبة في ذلك الوقت.

الخطوة 1: الترتيب حسب عمود CPU%

عند تشغيل htop، رتب العمليات حسب استخدام المعالج. على سبيل المثال، إذا كانت العمليات مثل php-fpm أو php أو python3 أو node أو java أو mysqld تظهر باستمرار في المراتب العليا، فقم بتدوين هذه العملية. قد يبدو أن الاستخدام بنسبة 100% في نظام أحادي النواة هو الحد الأقصى الطبيعي، بينما يمكن أن تظهر عملية في نظام متعدد النوى بقيم مثل 200% أو 400%، مما يعني أنها تستخدم عدة نوى.

الخطوة 2: تدوين معلومات PID و USER

قم بتدوين رقم PID للعملية المشبوهة ومعلومات USER. على سبيل المثال، إذا كان PID هو 24819، وUSER هو siteuser، وفي حقل COMMAND ترى php /home/siteuser/public_html/wp-cron.php، فإن هناك احتمالًا كبيرًا أن المشكلة مرتبطة بآلية cron أو ووردبريس في الموقع المعني. إذا كان حقل COMMAND قصيرًا جدًا، يمكنك تفعيل عرض النص الكامل من إعدادات htop أو الحصول على التفاصيل باستخدام أمر ps.

الخطوة 3: رؤية الأمر الحقيقي للعملية

لرؤية سطر الأوامر التفصيلي من خلال PID، يمكن استخدام الأمر التالي:

ps -fp PID

استخدام المثال:

ps -fp 24819

عادةً ما تُظهر هذه الإخراجات من أي ملف يتم تشغيل السكربت. إذا كان الأمر يظهر كـ php /home/kullanici/public_html/index.php، فقد يكون طلب ويب ناتج عن حركة مرور. إذا كان يظهر كـ php /home/kullanici/public_html/wp-content/plugins/bilinmeyen-eklenti/task.php، فقد تكون هناك مشكلة متعلقة بالمكون الإضافي.

الخطوة 4: التحقق من مسار الملفات والملفات المفتوحة

لرؤية الملفات التي تستخدمها عملية معينة، تعتبر أداة lsof مفيدة جدًا:

lsof -p PID

هذا الأمر يظهر الملفات، والمكتبات، والسجلات، والاتصالات الشبكية التي تحتفظ بها العملية. في بيئات استضافة الويب، يمكن أن يساعدك هذا الإخراج في فهم أي دليل موقع نشط. على سبيل المثال، إذا رأيت ملف PHP يحمل اسمًا غريبًا داخل /home/example/public_html/wp-content/uploads، فقد يكون هذا علامة على خرق أمني. في مثل هذه الحالة، فإن إنهاء العملية ليس كافيًا؛ يجب إجراء تنظيف للملف، وتغيير كلمات المرور، وتحديث المكونات الإضافية، وإجراء فحص أمني. يمكن أيضًا مراجعة صفحة حلول شهادات SSL لإعدادات SSL والاتصالات الآمنة.

العثور على السكربتات التي تستهلك الذاكرة باستخدام htop

مشاكل الذاكرة يمكن أن تتطور بشكل أكثر خفية من مشاكل المعالج. عندما يرتفع استخدام المعالج، عادة ما تشعر بتباطؤ فوري؛ لكن عندما تنفد الذاكرة، قد تغلق الخدمات بطريقة غير متوقعة، مع استخدام مكثف للذاكرة الافتراضية، ويزداد التأخير في جميع أنحاء الخادم. يمكنك ترتيب العمليات حسب عمود MEM% في شاشة htop للحصول على قائمة بأكثر العمليات استخدامًا للذاكرة.

فهم علاقة MEM% و RES و Swap

htop يعرض نسبة MEM% في العرض الافتراضي. في بعض التكوينات، قد تظهر أيضًا أعمدة VIRT و RES و SHR. عند إجراء تحليل للذاكرة، تكون قيمة RES مهمة بشكل خاص؛ لأنها تعبر عن المساحة الفعلية التي تستخدمها العملية في الذاكرة الفعلية. قيمة VIRT ليست دائمًا تعني استهلاك الذاكرة الفعلية، لذلك يمكن أن تكون مضللة بمفردها.

على سبيل المثال، إذا كانت لديك VPS بها 4 جيجابايت من الذاكرة، فإن استخدام عملية PHP واحدة لـ 900 ميجابايت من RES ليس أمرًا طبيعيًا. بالمثل، إذا ارتفع استخدام تطبيق Node.js من 200 ميجابايت إلى 1.5 جيجابايت مع مرور الوقت، فقد يشير ذلك إلى احتمال وجود تسرب في الذاكرة. أما بالنسبة لـ MySQL أو MariaDB، فقد يكون استخدام الذاكرة العالي أحيانًا سلوكًا طبيعيًا لذاكرة التخزين المؤقت؛ في هذه الحالة، يجب تقييم أداء الاستعلام، وإعدادات التخزين المؤقت، وإجمالي الذاكرة في النظام معًا.

الأسباب النموذجية لتسرب الذاكرة في السكربتات

• شفرة PHP أو Python أو Node.js تدخل في حلقة لانهائية
• تحميل ملفات CSV أو XML أو JSON الكبيرة في الذاكرة دفعة واحدة
• المكونات الإضافية غير المحسّنة في ووردبريس ووظائف القالب
• عمليات معالجة الصور، وإنتاج PDF، أو تحويل الفيديو
• استعلامات ثقيلة متكررة بسبب عدم كفاية استخدام التخزين المؤقت
• حركة مرور الروبوتات أو الهجمات التي تجعل نفس السكربت يعمل عدة مرات
• خدمات الخلفية الطويلة التي تحتوي على تسرب في الذاكرة

في مثل هذه الحالات، فإن مجرد إغلاق العملية باستخدام أمر kill يوفر راحة مؤقتة. يجب تحليل ما يقوم به السكربت، وما هي المدخلات التي تسببت في استمراره، ولماذا لا يتم تحرير الذاكرة.

البحث والتصفية وعرض الشجرة داخل htop

إذا كان هناك مئات العمليات تعمل على الخادم، يصبح من الصعب البحث يدويًا في القائمة. يوفر htop اختصارات مفيدة في هذا الصدد. يمكنك البحث باستخدام F3، وتطبيق تصفية باستخدام F4، والانتقال إلى عرض الشجرة باستخدام F5. يعد عرض الشجرة مهمًا بشكل خاص لرؤية العلاقة بين الأبوين والأبناء. يمكنك رؤية العمليات الفرعية لـ php-fpm التي تعمل تحت nginx أو Apache، أو السكربتات التي يتم تشغيلها تحت cron، أو خدمات Node.js التي يتم إدارتها بواسطة supervisor بشكل أوضح.

أمثلة عملية على التصفية

• اكتب php لعرض السكربتات الخاصة بـ PHP فقط.
• اكتب python لتصفية السكربتات الخاصة بـ Python.
• اكتب wp-cron للتحقق من سلوك cron الخاص بـ ووردبريس.
• اكتب node لفحص تطبيقات Node.js.
• قم بتصفية باسم المستخدم لرؤية عمليات حساب استضافة واحدة.

تساعد هذه الفلاتر، خاصة في الخوادم متعددة المستخدمين، على توفير الوقت. إذا كان هناك 30 موقعًا مختلفًا مستضافًا على نفس الخادم، يمكن فحص عمود USER ومسار الأمر معًا لفهم مصدر المشكلة بسرعة. إذا كنت ترغب في تبسيط الجانب الإداري لمشاريعك المستندة إلى الدومين، يمكنك مراجعة صفحة استعلام عن النطاق والتسجيل.

خطة تدخل آمنة للتعامل مع PID المشبوه

عند العثور على عملية تستهلك الموارد، قد يبدو من المغري استخدام kill -9 على الفور. ومع ذلك، قد تؤدي هذه المقاربة إلى فقدان البيانات، أو العمليات الكتابية التي لم تكتمل، أو عدم اتساق الخدمة. يجب اتباع خطة أكثر أمانًا.

1. وثق العملية

ابدأ بتدوين PID وUSER وCOMMAND وCPU% وMEM% والوقت. إذا أمكن، قم بأخذ لقطة شاشة لـ htop. ستساعد هذه السجلات في إجراء مقارنة في حال حدوث المشكلة مرة أخرى. تعتبر هذه البيانات مفيدة خاصة عند تقديم تفسير تقني للعميل في المشاريع المتعلقة بالوكالات أو التجارة الإلكترونية أو الشركات.

2. تحقق من مسار العملية

تحقق من مسار العملية باستخدام ps -fp PID و lsof -p PID. إذا كان الملف موجودًا في الدليل الجذر للموقع، تحقق من سجلات التطبيق ذات الصلة. بالنسبة لووردبريس، تعتبر wp-content/debug.log، وسجل الوصول وسجل الأخطاء لخادم الويب، وسجل slow لـ PHP-FPM من أهم الأدلة.

3. حاول إنهاء العملية بلطف أولاً

إذا كانت العملية خارج السيطرة، أرسل أولاً إشارة إنهاء قياسية:

kill PID

انتظر بضع ثوانٍ وتحقق في شاشة htop مما إذا كانت العملية قد أغلقت أم لا. إذا لم تغلق وإذا كانت تؤثر بشكل كبير على صحة النظام، يمكن استخدام الأمر التالي كملاذ أخير:

kill -9 PID

إشارة kill -9 تنهي العملية دون منحها فرصة لتنظيف نفسها. لذلك، يجب استخدامها بحذر لعمليات قواعد البيانات، وعمليات الكتابة، أو مهام النسخ الاحتياطي.

4. إذا كانت تعيد البدء، ابحث عن المحفز

إذا قمت بإغلاق عملية لكنها تعود للبدء في غضون ثوانٍ، قد يكون هناك cron أو خدمة systemd أو supervisor أو طلب ويب أو حركة مرور للروبوتات وراء ذلك. يجب مراجعة سجلات cron باستخدام crontab -l، حالة الخدمة باستخدام systemctl status service، وسجل الوصول لفحص حركة مرور الويب. إذا كانت المشكلة ناتجة عن wp-cron في ووردبريس، يجب مراجعة تكوين cron الفعلي وسياسة التخزين المؤقت.

دمج اكتشافات htop مع السجلات

يوفر لك htop رؤى حول ما يستهلك الموارد؛ بينما تساعدك السجلات على فهم سبب الاستهلاك. إذا لم يتم استخدام هذين النوعين من البيانات معًا، فإن التشخيص سيكون ناقصًا. على سبيل المثال، قد يكون هناك عملية php-fpm تستهلك 180% من CPU في htop؛ لكن بدون سجل الوصول، قد لا تتمكن من رؤية أي URL أو أي روبوت يحفز هذه العملية.

بعض أمثلة السجلات التي يمكن فحصها هي:

• سجل وصول خادم الويب: يظهر URLs التي تتلقى طلبات عالية.
• سجل أخطاء خادم الويب: يظهر أخطاء PHP، وأذونات الملفات، والأخطاء 500.
• سجل slow لـ PHP-FPM: يظهر الملفات والدوال التي تعمل ببطء.
• سجل الاستعلامات البطيئة لـ MySQL: يحدد الاستعلامات الثقيلة.
• سجل المصادقة أو السجل الآمن: يظهر محاولات الدخول المشبوهة.
• سجل cron: يظهر متى تعمل المهام المبرمجة.

على سبيل المثال، إذا رأيت PID يستهلك CPU عالي في htop، وفي نفس الدقيقة كان هناك آلاف الطلبات على /wp-admin/admin-ajax.php في سجل الوصول، فإن المشكلة قد تكون مرتبطة بمكون إضافي، أو حركة مرور روبوتات، أو عملية AJAX مصممة بشكل سيء. في هذه الحالة، يجب النظر في WAF، وتحديد معدلات الطلب، والتخزين المؤقت، وتحسين المكونات الإضافية معًا. لمزيد من التحليل لأداء الموقع على نطاق أوسع، يمكن أن تكون معلومات تحسين سرعة الموقع مفيدة.

كيف تميز بين الحمل العادي والحمل المشتبه فيه؟

لا تعني كل زيادة في استخدام الموارد حدوث أزمة. يجب مراعاة عتاد الخادم، ومستوى الحركة، ونوع التطبيق، وإجراءات الصيانة. بالنسبة لـ VPS ثنائي النواة، فإن بقاء قيمة متوسط التحميل لفترة طويلة عند 6-8 هو مؤشر على عنق زجاجة خطير. بينما قد يكون نفس القيمة طبيعية على خادم مخصص بـ 16 نواة. لذلك، يجب معرفة عدد النوى عند تفسير متوسط التحميل.

تساعد هذه المقارنة في التمييز بين الذعر غير الضروري وأزمة الأداء الحقيقية. خاصة في مواقع التجارة الإلكترونية، قد تتسبب فترات الحملة، وتكامل الدفع، وتحديثات المخزون في زيادة مؤقتة في الموارد. ومع ذلك، إذا كان هذا الارتفاع يؤثر على تجربة المستخدم، يجب تقييم تحسين التطبيق وسعة الخادم معًا.

الشكوك الأمنية: هل يمكن أن يكون السكربت الذي يستهلك الموارد ضارًا؟

قد لا يكون السكربت الذي يستهلك CPU أو الذاكرة دائمًا خطأً بريئًا. في المواقع الإلكترونية المخترقة، يمكن للمهاجمين تشغيل إرسال الرسائل العشوائية، أو تعدين العملات، أو حركة مرور الوكالة، أو روبوتات DDoS، أو سكربتات الباب الخلفي. يجب أن تؤخذ الأوامر الغريبة التي تعمل تحت مستخدم غير متوقع، والأسماء العشوائية للملفات، والملفات الثنائية التي تعمل من /tmp، أو الملفات PHP التي تعمل داخل public_html/uploads على محمل الجد من الناحية الأمنية.

علامات مشبوهة

• أسماء ملفات غير مفهومة أو عشوائية في حقل COMMAND
• ملفات تعمل من /tmp أو /dev/shm أو دليل uploads
• عمليات perl أو python أو bash التي لا ينبغي أن تكون موجودة عادةً
• عمليات تُنشئ اتصالات خارجية عالية
• نفس المستخدم يبدأ عددًا كبيرًا من العمليات في فترة زمنية قصيرة
• تغييرات غير مصرح بها حديثًا في ملفات الويب

في حالة حدوث ذلك، حاول الحصول على مخرجات الأوامر كأدلة قبل إغلاق العملية. بعد ذلك، تحقق من أذونات الملفات، وقم بعزل الملفات الضارة، وغيّر جميع كلمات المرور للوحة التحكم وCMS، وحدث ملفات المكونات الإضافية والقوالب الأساسية، وأجرِ فحصًا أمنيًا. بالإضافة إلى ذلك، فإن استخدام المصادقة الثنائية في لوحات التحكم وإزالة الأذونات الكتابية غير الضرورية يساعد على تقليل المخاطر على المدى الطويل.

أفضل الممارسات لمنع تكرار مشاكل الأداء

من المهم العثور على المشكلة باستخدام htop؛ لكن القيمة الحقيقية تكمن في منع حدوث نفس المشكلة مرة أخرى. تساعد التدابير التالية في تقليل الانقطاعات الناجمة عن CPU والذاكرة بشكل كبير في خوادم لينكس.

• قم بضبط قيم PHP مثل memory_limit وmax_execution_time وpm.max_children حسب سعة الخادم.
• استخدم آلية التخزين المؤقت في ووردبريس أو Joomla أو البرمجيات المخصصة.
• قم بإزالة المكونات الإضافية والقوالب والوحدات غير الضرورية.
• قم بتحسين الاستعلامات الثقيلة باستخدام سجل الاستعلامات البطيئة في MySQL.
• لا تجمع مهام cron في نفس الدقيقة؛ قم بتشغيلها بفواصل زمنية.
• تطبيق قيود السرعة، وملف robots.txt، وقواعد جدار الحماية لحركة مرور الروبوتات.
• قم بتدوير سجلات التطبيق بانتظام؛ راقب تأثير ملفات السجل الضخمة على القرص والذاكرة.
• راقب مقاييس الخادم بانتظام، وليس فقط في أوقات الأزمات.

إذا استمرت استخدام الموارد في الارتفاع على الرغم من التحسينات، فقد لا تكون المشكلة فقط في الجانب البرمجي. قد تكون حركة المرور قد ارتفعت، أو أن التطبيق قد نما، أو أن حزمة الاستضافة الحالية لم تعد كافية. في هذه الحالة، يصبح من المنطقي الانتقال إلى VPS قابل للتوسع، أو زيادة الذاكرة، أو استخدام قرص NVMe أسرع، أو خادم ذو موارد معزولة. يمكنك مقارنة الخيارات من خلال حزم الاستضافة و حلول الخوادم المؤسسية.

سيناريو مثال: انفجار CPU في موقع ووردبريس

دعونا نتابع سيناريو واقعي. يعمل عدة مواقع ووردبريس على VPS تحتوي على 4 نوى و 8 جيجابايت من الذاكرة. يشتكي المستخدمون من أن الموقع يبطئ في بعض الأحيان، ويتلقون خطأ 502. عند فتح htop في الطرفية، يظهر متوسط التحميل عند مستوى 12، وجميع نوى المعالج مشغولة، وتظهر العديد من عمليات php-fpm التي تعود لنفس المستخدم في المراتب العليا.

يتم تصفية أسماء المستخدمين باستخدام F4. يتم تدوين PID لأحد العمليات التي تستهلك CPU. في مخرجات ps -fp PID، يظهر php-fpm worker؛ من خلال lsof -p PID، يتم ملاحظة الوصول إلى /home/site/public_html/wp-content/plugins/example-importer/import.php. عند مراجعة سجل الوصول، يتم رؤية طلب إداري يحفز هذا الملف في نفس الدقائق، بالإضافة إلى استدعاءات AJAX المتكررة.

كحل، يتم إيقاف عملية الاستيراد، وإغلاق المهمة المجدولة للمكون الإضافي، وتقسيم عملية استيراد البيانات الكبيرة إلى أجزاء، ويتم إعادة ضبط الحد الأقصى لـ PHP max_execution_time. بالإضافة إلى ذلك، يتم استخدام cron النظام بدلاً من wp-cron. ونتيجة لذلك، ينخفض متوسط التحميل من 12 إلى 1.8، ويعود استخدام CPU إلى الطبيعي، وتتحسن أوقات استجابة الويب بشكل ملحوظ. هذه الحالة توضح مدى كفاءة استخدام htop عندما يتم استخدامه مع ps و lsof وتحليل السجلات معًا.

الأخطاء الشائعة عند استخدام htop

• إغلاق أعلى عملية فقط دون التحقيق في السبب الجذري.
• اعتبار قيمة VIRT كمؤشر حقيقي لاستخدام الذاكرة.
• التعامل مع استخدام الذاكرة RAM من قبل MySQL كمسألة مباشرة.
• استخدام kill -9 كخيار أول.
• إلقاء اللوم على التطبيق أو المستخدم دون مراجعة السجلات.
• تفسير قيمة متوسط التحميل بدون النظر إلى عدد النوى.
• عدم فحص سلامة الملفات في حالة الشك في خرق الأمان.

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

أسئلة شائعة

ما فائدة أمر htop في خادم لينكس؟

يوفر أمر htop في خادم لينكس عرضًا في الوقت الحقيقي للعمليات الجارية، بما في ذلك معلومات CPU والذاكرة والمستخدم وPID والأوامر. وبالتالي، يمكنك اكتشاف السكربتات التي تستهلك المعالج أو الذاكرة بسرعة.

كيف أجد السكربت الذي يستهلك CPU باستخدام htop؟

رتب العمليات في شاشة htop حسب عمود CPU%، دوّن رقم PID ومعلومات USER للعملية التي تبقى لفترة طويلة في الأعلى. ثم تحقق من مسار السكربت باستخدام ps -fp PID و lsof -p PID.

هل يجب أن أعتبر MEM% أو VIRT عند تحليل استهلاك الذاكرة؟

عند تحليل الذاكرة، تعتبر قيم MEM% وRES أكثر دلالة. لا تعني قيمة VIRT دائمًا استهلاك الذاكرة الفعلية، لذا فهي قد تكون مضللة بمفردها.

هل من الصحيح إغلاق العملية المستهلكة للموارد باستخدام kill -9 على الفور؟

عادةً لا. من الأفضل أولاً توثيق ما تفعله العملية، والتحقق من مسار الملف، وتجربة kill PID. يجب استخدام kill -9 فقط كملاذ أخير إذا كانت العملية لا تغلق وتؤثر بشكل كبير على صحة الخادم.

هل يعني ارتفاع استخدام CPU في htop دائمًا وجود هجوم؟

لا. قد تؤدي النسخ الاحتياطية، أو الاستيراد، أو إنشاء التخزين المؤقت، أو حركة المرور الكثيفة إلى زيادة استخدام CPU. ومع ذلك، فإن أسماء الملفات العشوائية، والعمليات من /tmp أو uploads، والعمليات التي تعمل تحت مستخدم غير متوقع تثير الشكوك بشأن الأمان.

باختصار، يعد أمر htop في خادم لينكس نقطة انطلاق سريعة وعملية للعثور على السكربتات التي تستهلك المعالج والذاكرة. للحصول على النتائج الأكثر دقة، يجب دمج بيانات htop مع تحليل PID، وإخراج lsof، والتحقق من cron وفحص السجلات. إذا كانت لديك مشاكل متكررة في الموارد، يجب تقييم تحسينات البرمجيات وسعة البنية التحتية معًا؛ في حالة الحاجة، يمكنك مقارنة حلول الاستضافة وVPS وSSL من Hostragons دون ضغط بيعي لاختيار البنية الأنسب لمشروعك.