برنامج تعليمي لحل وحدة المعالجة المركزية لخادم Alibaba Cloud

بالنسبة إلى التشغيل والصيانة والتطوير ، فإن رسالة التنبيه النصية الأكثر إيقاعًا في منتصف الليل هي "لقد وصل معدل استخدام وحدة المعالجة المركزية لنظام مثيل ECS الخاص بالخادم السحابي إلى 100 ٪."

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

يأخذك هذا البرنامج التعليمي اليوم مثل المخضرم ذو الخبرة ، ويحل بهدوء وتوحيد مشكلة التحميل الكامل لوحدة المعالجة المركزية لخادم Alibaba Cloud.

المرحلة الأولى: التحقيق في سوء الفهم والتحضير لـ "رؤية الطبيب"

قبل أن تطرق الأوامر ، اذهب

علي وحدة التحكم السحابية

ألق نظرة على مراقبة السوق لتأكيد مؤشر رئيسي:

تكامل وحدة المعالجة المركزية من النوع الأساسي (T-series)

.

إذا كنت تشتري "مثيلات الأداء المفاجئة" لـ Alibaba Cloud (مثل t5 و t6) ، فإن هذا الخادم عادةً ما يحد من قوة حساب وحدة المعالجة المركزية الأساسية (مثل إعطاء 20 ٪ فقط). عندما يتجاوز عملك المعيار ، سوف تستهلك "نقاط وحدة المعالجة المركزية" للحصول على قوة الحساب الكاملة. بمجرد استنفاد النقاط ، سيتم إجبار الخادم على "الحد الأقصى للسرعة" ، مما يدل على أن وحدة المعالجة المركزية مغلقة في درجة منخفضة معينة وأن بطاقة النظام ستكون غير متحركة.

الحل: إذا تم استنفاد مثيل الأداء المفاجئ ، فإما تشغيل "الوضع غير المقيد بالأداء" في وحدة التحكم ، أو الترقية مباشرة إلى مثيل "عام" أو "حساب".

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

المرحلة الثانية: يتم تحميل وحدة المعالجة المركزية لخادم Linux بالكامل بخطوات كاملة

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

الخطوة الأولى: اكتشف الجاني في قوة الحساب "الأكل" (

أعلى

الأمر)

استخدم SSH للاتصال بالخادم ، وأدخل الأمر العالمي في جميع أنحاء الكون مباشرة في المحطة:

باش

أعلى

بعد الدخول إلى الواجهة التفاعلية ، اضغط على الأحرف الكبيرة على لوحة المفاتيح

(ع)

(Shift + p) ، دع العمليات مرتبة حسب استخدام وحدة المعالجة المركزية من الأعلى إلى الأدنى.

راقب الأسطر القليلة الأولى عن كثب ولاحظ الحقول الأساسية الثلاثة التالية:

PID: رقم هوية العملية ، وتعتمد عملية القتل اللاحقة عليه.

USER: المستخدم الذي بدأ العملية. إذا كان www أو nginx ، فإن الاحتمال الكبير هو مشكلة رمز ؛ إذا كان جذر وكان الاسم غريبًا ، احذر من أنه حصان طروادة.

COMMAND: اسم العملية.

تحليل المشتبه بهم COMMAND المشترك:

Php-fpm ، java ، node ، python: يتم تشغيل رمز العمل في حلقة لا نهاية لها ، أو لا يتم فهرسة قاعدة البيانات في ظل التزامن العالي ، مما يؤدي إلى حمل صعب.

Mysql: تقوم قاعدة البيانات بإجراء استعلامات ارتباط معقدة ومسح جدول كامل.

Kswapd0: ذاكرة النظام ليست كافية ، ويتم نقل بيانات الذاكرة بشكل محموم إلى قسم Swap من القرص الصلب ، مما يتسبب في ارتفاع وحدة المعالجة المركزية.

Kinsing ، sysrv ، سلسلة من الرموز العشوائية: مبروك ، تم اختراق الخادم ، هذا هو حصان طروادة الكلاسيكي.

الخطوة الثانية: التقشير العميق ، انظر ماذا تفعل داخل العملية

إذا وجدت أن الكود الخاص بك (مثل عملية Java أو PHP) ممتلئ وحدة المعالجة المركزية ، فلا يكفي معرفة PID ، وعليك معرفة أي سطر من التعليمات البرمجية هو الشيطان.

السيناريو أ: عملية Java مليئة بالتحقيق (المقابلات الكلاسيكية وأسئلة القتال الفعلية)

لنفترض أن PID عملية Java المحملة بالكامل هو

1234

.

ابحث عن رقم مؤشر الترابط (TID) الذي يستهلك وحدة المعالجة المركزية أكثر في هذه العملية: يفترض Bashtop -Hp 1234 أن مؤشر الترابط 1256 يمثل 90 ٪ من وحدة المعالجة المركزية.

تحويل هذا الخيط إلى نظام سداسي عشري (لأن مكدس Java يستخدم نظام سداسي عشري):Bashprintf "٪ x \ n" 1256 # يفترض نتيجة الإخراج: 4e8

استخدم أداة jstack لطباعة مكدس خيط Java ، واستخدم grep للاستيلاء على رقم الخيط المكون من ستة عشري: Bashjstack 1234 | grep -A 20 "4e8" سيتم عرض أي فئة وأي سطر من التعليمات البرمجية مباشرة على الشاشة (مثل com.xx.. impl.OrderServiceImpl.lambda $0(OrderServiceImpl.java:88)) قيد التشغيل ، الحلقة الميتة واضحة في لمحة.

السيناريو ب: MySQL يتسبب في امتلاء وحدة المعالجة المركزية

إذا كان الأمر كذلك

Mysql

احتلت العملية المرتبة الأولى. قم بتسجيل الدخول إلى قاعدة البيانات للتنفيذ على الفور:

إس كيو إل

عرض قائمة العمليات الكاملة؛

تحقق من عبارات SQL التي يتم تنفيذها حاليًا. التركيز على

الوقت

(وقت التنفيذ) أطول تلك العبارات ، إذا رأيت عددًا كبيرًا

Selecting

قم بإخطار المطور والفهرسة مباشرةً باستخدام SQL الفاسد في حالة عدم وجود فهرسة ، أو دع DBA يقتل هذا SQL الفاسد مؤقتًا.

الخطوة الثالثة: التخلص الحاسم (كيفية الانتهاء برشاقة)

الحالة 1: الحلقة الميتة للرمز العادي

إذا كان التأثير على البقاء على قيد الحياة ، يمكنك أولاً استخدام PID لقتل العملية مقابل وقت الراحة:

باش

عملية kill -9 PID

ثم اسرع لتغيير الرمز Bug.

الحالة 2: لقد حصلت على حصان طروادة

عادة ما يقوم المتسللون بالمهام الموقوتة ، أنت بسيط

Kill-9

لا يمكن قتله ، وسوف يتم إحياؤه في ثانية واحدة.

تحقق من مهمة التوقيت: crontab -l ، وجدت أن هناك برنامج تنزيل غريب ، على الفور مع cron

تم حذف tab -e.

فحص العمليات المتبقية والقتل.

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

المرحلة الثالثة: يتم تحميل وحدة المعالجة المركزية لخادم Windows بالكامل بخطوات كاملة

خوادم ويندوز بديهية نسبيا ، وحلها مباشرة من خلال واجهة رسومية.

الخطوة الأولى: افتح مدير المهام

يتصل سطح المكتب البعيد بالخادم.

انقر بزر الماوس الأيمن على شريط المهام السفلي ، واختر مدير المهام.

انقر على رأس عمود وحدة المعالجة المركزية للسماح له بالفرز حسب الاستخدام من الأعلى إلى الأدنى.

الخطوة الثانية: التعمق في مراقبة الموارد

يمكن لمديري المهام في بعض الأحيان رؤية فقط

W3wp.exe

(عملية IIS) أو

Sqlservr.exe

عالية جدا ، لا يمكن رؤية التفاصيل.

في الجزء السفلي من إدارة المهام ، انقر على فتح مراقب الموارد.

التبديل إلى علامة التبويب وحدة المعالجة المركزية.

هنا يمكنك أن ترى خدمات محددة لكل عملية. إذا كان w3wp.exe يرتفع ، فهذا يعني أن هناك مشكلة في رمز موقع ويب معين على IIS. يمكنك التحقق من عنوان URL الخاص بموقع الويب الذي يستهلك الموارد بشكل محموم من خلال "عملية العمل" في IIS.

المرحلة الرابعة: الوقاية خير من العلاج-كيف تمنع وحدة المعالجة المركزية من الحصول على كامل مرة أخرى ؟

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

قم بتكوين "قاعدة إنذار وحدة المعالجة المركزية" في Alibaba Cloud Console: أدخل مراقبة السحابة-> حزمة التطبيق أو مراقبة المضيف. أضف إنذارًا إلى الخادم: عندما يستمر استخدام وحدة المعالجة المركزية> = 85 ٪ لمدة 5 دقائق ، أرسل رسالة نصية/مسمار إلى الهاتف المحمول على الفور. تدخل في وقت مبكر قبل أن تصل إلى 100 ٪.

تضيف قاعدة البيانات "سجل الاستعلام البطيء": افتح slow_query_log لـ MySQL ، واسجل جميع SQL التي يزيد وقت تنفيذها عن ثانية واحدة. يتم توزيعها على التطوير والتحسين كل يوم للقضاء على الأخطار الخفية في مهدها.

تعيين آلية المهلة في طبقة الكود: سواء كانت مكالمة API خارجية أو حلقة معقدة أو خيوط متعددة ، يجب تعيين الحد الأقصى لوقت المهلة. لا تدع حلقة ميتة معلقة إلى أجل غير مسمى.

الخلاصة

التحقيق في وحدة المعالجة المركزية محملة بالكامل مثل القبض على لص:

استخدم أولاً top/task Manager لقفل المشتبه به (PID) ، ثم استخدم jstack / PROCESSLIST للحصول على دليل جنائي (أي سطر من التعليمات البرمجية/أي SQL) ، وأخيراً تعامل معه بشكل حاسم وقم بتركيب إنذار مراقبة

.

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