حسنًا ، كما لاحظت على الأرجح ، كانت مدونتي معطلة عمليًا من مساء السبت 21:30 مساءً إلى مساء الاثنين هذا ثم تم حظرها ، من الواضح للسبب التالي:
لقد لاحظنا أن الخادم الخاص بك يستخدم قدرًا كبيرًا من طاقة المعالج. يمكن أن يكون لهذا الأسباب التالية ، من بين أمور أخرى:
أ) نص برمجي معيب (PHP ، CGI ، إلخ.)
ب) نص برمجي غير فعال
ج) المكونات الإضافية ووظائف cron من تطبيقات الويب (CMS ، المعرض ، إلخ.)لمنع المزيد من الضرر ، اضطررنا إلى قفل الخادم الخاص بك على الفور.
إنه لأمر مخز ، ولكنه مفهوم إلى حد ما ، بعد كل شيء ، هذه استضافة مشتركة وإذا كان خادم الويب الخاص بي يستخدم كل القوة ، فلا شيء يبقى على الخادم للعملاء الآخرين ، وبالتالي لا أحد يستمتع بالموقف حقًا. لا يزال من العار أن يتم حظر حسابي بالكامل ، بما في ذلك لوحة التحكم ، وأنه لم يكن من الممكن أن أبدأ تحليل ملف السجل ، للأسباب التالية:
يرجى إرسال بيان موجز ووقت خلال ساعات العمل يمكنك من خلاله معالجة المشكلة. سنقوم بعد ذلك بإلغاء حظر الخادم في أقرب وقت ممكن حتى تتمكن من الوصول مرة أخرى.
إذا كانت لديك أي أسئلة أخرى ، فلا تتردد في الاتصال بنا. يمكنك الوصول إلينا إما عبر الخط الساخن 0900 xxx xxx (1.49 فرنك سويسري / دقيقة) أو عبر البريد الإلكتروني على support@xyz.ch.
PENG! وذهبت مدونتي
في ذلك السبت ، أجريت ترقية WP 2.8.5 وكنت على وشك تبادل ملفات اللغة عندما طار الخادم 17 بالكامل في أذني. بطريقة ما كانت قاعدة البيانات في حلقة لا نهاية لها ، تتأرجح بين إعادة التشغيل والتوفر لبضع ثوان ومن الواضح أنها تملأ الذاكرة. في ذلك الوقت ، لم أستطع أن أتخيل أن تبادل ملفات اللغة يمكن أن يكون سبب الحمل الزائد على الخادم.
لذلك يجب أن يكون شيئًا آخر ، لأنه عادةً ما يعني الحمل الكبير في حالة WordPress أن قاعدة البيانات يتم إجراؤها كثيرًا أو أن المكون الإضافي لا يعمل كما ينبغي (تمت برمجته بشكل غير صحيح أو ما شابه) ، على الأقل شيء من هذا القبيل يمكن أن يكون التي تم العثور عليها عند استخدام برنامج Sends guys from Google (تقليل استخدام وحدة المعالجة المركزية في WordPress # 1 أودر تقليل وحدة المعالجة المركزية وتسريع وقت التحميل). نظرًا لأنني قمت بتشغيل مكون إضافي جديد فقط يوم الجمعة ، فيمكن أن يكون هذا أو الترقية.
تؤدي إعادة تشغيل خادم الويب الخاص بي صباح الاثنين إلى نفس المعضلة كما حدث مساء السبت ، بطريقة ما لم يعد DB تهدأ بعد الآن. لذلك خطرت لي فكرة نسخ دليل البرنامج المساعد WordPress بالكامل أولاً على الموقع ، حيث اشتبهت الدودة في وجودها. رائع ، لا تؤدي إعادة التشغيل إلى تكرار التكرار مرة أخرى ، لكن WordPress كان ميتًا. لذا ، ابدأ العمل واستعد المكونات الإضافية ببطء ، والتي عملت بشكل جيد باستثناء ملحقات التخزين المؤقت. وبالتالي ، بمجرد حذف التخزين المؤقت وإعادة تحميله على الخادم وتنشيطه و يوريكا! أنه يعيش!
لذلك اعتقدت في البداية أن المكونات الإضافية للتخزين المؤقت هي المسؤولة عن المشاكل. ولكن عند الفحص الدقيق ، أصبحت الخلفية الإدارية الخاصة بي فجأة باللغة الإنجليزية تمامًا وبدا هذا غريبًا بعض الشيء. هل تتذكر بالتأكيد التحديث المذكور لملفات اللغة من يوم السبت؟ بالضبط ، ما زلت مسجلة مع .......- PENG! وداعا ديسيبل!
في البصيرة الحكيمة ، كان لدي بالفعل تثبيت WP إضافي جديد يعمل في نفس الوقت وجربت حظي هناك مع ترقية بيانات اللغة ... PÄNG! ذهب DB! لذلك كان لدينا الجاني! وكما يمكن تحديده بالفعل ، كنت قادرًا على ذلك WordPress ألمانيا اقرأ ما يلي:
هناك أخطاء محرجة حقًا ، مثل هذا ، على سبيل المثال. إنه نوع من الخطأ الذي يحب الناس الإشارة إليه على أنه "كيف يمكنك أن تكون بهذا الغباء".
ماذا حدث؟ جاء WordPress 2.8.5 بمثابة مفاجأة يوم الأربعاء وكنت مسؤولاً عن استيراد النسخة الألمانية على de.wordpress.org ، والتي تُستخدم أيضًا كمصدر للتحديث التلقائي. أتمتة هذا النظام بسيطة للغاية: قم بتحميل ملف اللغة إلى SVN ، نقرتين والإصدار جاهز. لولا الدور البشري في هذه العملية.
حسنا البنغو! بعد آخر تحديث غير ناجح (لا أذكر الإصدار الآن ، فقط قل التحديث التلقائي) لا تستخدم الأتمتة ثم شيء من هذا القبيل. الحظ السيئ ، يمكن أن يحدث لأي شخص ، كان سيكون من الجيد لو كلفني القليل من الجهد ، ولم يركع الخادم على ركبتيه وتسبب في تعطل مدونتي لفترة طويلة جدًا. لأنني افتقدت القبو قليلاً ، وكما تمكنت من معرفة ذلك من رسائل البريد الإلكتروني الخاصة بك ، فأنت أيضًا. شكرا لسؤالك!
بالمناسبة ، موضوع فرانكشتاين مُدرج كقميص RetroRebels مقابل 23.50 جنيهًا إسترلينيًا.
يا! يا! دعنا نذهب! مرحبًا بعودتك