كيفية تشخيص التباطؤ؟

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

يمكنني الخوض في تفاصيل ما حدث أكثر، لكنني أفضل طرح سؤال عام. ما هي بعض التقنيات لتشخيص سبب التباطؤ؟ يبلغ متوسط استخدام وحدة المعالجة المركزية (CPU) في القطرة الخاصة بي 20٪، لذا يبدو أن لدي موارد كافية (4 جيجابايت ذاكرة / 2 معالج افتراضي AMD / 80 جيجابايت قرص، ~ 15 ألف مشاهدة صفحة يوميًا)

أي نصائح موضع تقدير.

3 إعجابات

أول ما سأفعله هو
vmstat 5 5
على سطر الأوامر.

3 إعجابات

شكراً على الاقتراح. لست على دراية بالأمر، هل هناك شيء معين يجب أن أبحث عنه؟
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n r b swpd free buff cache si so bi bo in cs us sy id wa st\n 1 0 475136 144304 20296 1786100 2 3 2622 447 44 50 19 3 72 1 4\n 0 0 475136 143076 20304 1785312 0 0 65 25 622 584 2 1 95 0 1\n 0 0 475136 141080 20456 1789144 0 0 800 3 459 473 2 1 96 0 1\n 3 0 475136 143092 20572 1783408 0 17 11598 51 733 966 14 6 67 2 12\n 0 0 475648 134688 20376 1791036 0 81 38915 394 1323 1784 10 8 61 8 13\n

إعجاب واحد (1)

شكرًا لك! لو كانت هناك مشكلة في نقص الذاكرة، لكانت أرقام ذاكرة التخزين المؤقت صغيرة، ولو كان هناك تبديل صفحات كثير، لكانت أعمدة si و so كبيرة. لكن هذا ليس هو الحال.

نرى ذروة كبيرة في bi و bo، وهي عادةً نشاط القرص. أتساءل عما إذا كان شيء ما في مكان ما يقوم ببناء أو إصلاح أو مسح شيء ما.

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

هناك أدوات أخرى قد لا تكون مثبتة بالفعل: ربما ابحث عن “كيفية مراقبة مدخلات ومخرجات القرص في نظام لينكس” أو ما شابه.

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

5 إعجابات

هذه نصيحة رائعة، شكراً لك!

أنا أجلس عند استخدام 80% من الذاكرة. هل هذا طبيعي؟ الانخفاض ناتج عن إيقاف التطبيق وإعادة تشغيله باستخدام المشغل.

droplet: 4 جيجابايت ذاكرة / 2 معالج AMD vCPUs / 80 جيجابايت قرص

لقد قمت بتشغيل droplet جديد ووضعت نسخة احتياطية من المنتدى (بدون صور) وأحصل على سلوك مشابه.

مخرج htop، مرتب حسب الذاكرة:

80% لا تبدو مشكلة بالنسبة لي.

الأكثر إثارة للاهتمام هو أن لديك الكثير من عمليات sidekiq ومع ذلك أرى التعليق “0 من 5 مشغول” - لديك أكثر من 5. يبدو أن لديك أيضًا الكثير من خيوط unicorn.

أقترح موضوعًا جديدًا هنا، مع إخراج htop الخاص بك، بما في ذلك تكوين yml الخاص بك حول ما إذا كنت قد عدلت عدد unicorn الخاص بك. اسأل عما إذا كانت هذه المجموعة من العمليات تبدو معقولة.

لدي htop مشابه جدًا على نفس الخادم الافتراضي الخاص (معالج مختلف، مع ذلك) ولم أغير أي شيء من الإعدادات الافتراضية.

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

إعجاب واحد (1)

أجل، كان يجب أن أتحقق من htop الخاص بي: مشابه جدًا.

فكرة أخرى مختلفة تمامًا، للملاحظة الأصلية لـ “تباطؤ” - لتنشيط mini-profiler باستخدام Alt-P، ثم الوصول إلى صفحة كبيرة نموذجية على منتداك، ورؤية الاستعلامات التي يتم إجراؤها وكم تستغرق، عن طريق النقر على رقم التوقيت الذي يظهر في أعلى اليمين.

إعجاب واحد (1)

تمكنت من إجراء ترقية apt وإعادة البناء أيضًا. هذه المشكلة: Pups error on rebuild 🐕 كانت تمنعني من إعادة البناء لفترة من الوقت
منذ إعادة البناء، أشعر بتحسن. لا أحب العمل بناءً على الشعور في هذه الحالة، بل أفضل الحصول على تحليلات وبيانات قابلة للقياس. أقدر النصائح يا @Ed_S ستكون مفيدة للمراقبة الإضافية.
أتساءل عما إذا كان من الممكن التقاط بعض بيانات التوصيف هذه لإظهار “صحة” المثيل عبر صفحة المسؤول. ربما فكرة إضافة محتملة أو ميزة أساسية مستقبلية؟

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.