يؤدي حذف ذاكرة التخزين المؤقت لـ NGINX إلى وضع أخطاء إلغاء الارتباط الحرجة في سجل الأخطاء
نُشرت: ١٥ فبراير ٢٠٢٥ م في ١١:٢٣:١٢ ص UTC
تشرح هذه المقالة كيفية حذف العناصر من ذاكرة التخزين المؤقت لـ NGINX دون أن تتراكم رسائل الخطأ في ملفات السجل لديك. ورغم أن هذا النهج لا يُنصح به عمومًا، فقد يكون مفيدًا في بعض الحالات الشاذة.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
تعتمد المعلومات الواردة في هذه المقالة على التخزين المؤقت لـ FastCGI على NGINX 1.4.6 الذي يعمل على Ubuntu Server 14.04 x64. وقد تكون هذه المعلومات صالحة أو غير صالحة للإصدارات الأخرى.
(تحديث 2025: في الفترة بين كتابة المنشور الأصلي والآن، تغير الكثير. أصبحت الخوادم أسرع وأرخص، لذلك لن أوصي في الواقع بالنهج الموضح في هذا المنشور حيث أحاول إدارة انتهاء صلاحية ذاكرة التخزين المؤقت بدقة فقط لحفظ بضعة أجيال إضافية من المحتوى الديناميكي. سأترك المحتوى هنا للرجوع إليه في المستقبل وفي حالة احتياج شخص ما إليه بالفعل لأي سبب من الأسباب. لم أؤكد أن هذا لا يزال يعمل مع الإصدارات الحالية من NGINX، لكنني أعتقد أنه يعمل).
بعد نقل العديد من المواقع من Apache إلى NGINX، أصبحت مغرمًا جدًا بإمكانيات التخزين المؤقت المضمنة، والتي تعمل بشكل جيد للغاية في معظم الظروف دون تدخل كبير من جانبي.
ومع ذلك، بالنسبة لأحد المواقع، كنت بحاجة حقًا إلى القدرة على مسح ذاكرة التخزين المؤقت (بالكامل وإزالة الإدخالات الفردية) بنفسي. لا يدعم الإصدار المجاني للمجتمع من NGINX إلا انتهاء صلاحية ذاكرة التخزين المؤقت بناءً على الوقت (أي يمكنك إعداده للتحقق مما إذا كان هناك شيء قد تغير بعد ساعة أو يوم وما إلى ذلك). ولكن ماذا لو لم تكن هناك طريقة موثوقة لتحديد الوقت الذي سيتغير فيه مورد معين مسبقًا؟ على سبيل المثال، ليس لدي أي فكرة عما إذا كان الأمر سيستغرق ساعة أو يومًا أو عامًا قبل أن أعود وأعدل شيئًا في هذا المنشور - ولماذا يتم تخزينه مؤقتًا لمدة ساعة فقط إذا كان التخزين المؤقت ليوم واحد سيكون جيدًا؟
وهنا تبرز الحاجة إلى القدرة على مسح ذاكرة التخزين المؤقت يدويًا (أو من خلال جعل تطبيق الويب الخاص بك يخطر NGINX بضرورة مسح شيء ما). ومن الواضح أن القائمين على NGINX يدركون الحاجة إلى ذلك لأن هذه الميزة مدعومة في الإصدار المدفوع من منتجهم - ولكن في حين يحق لهم بالتأكيد إعداد ترخيصهم بأي طريقة يريدونها، فإن السعر مرتفع بعض الشيء بالنسبة لي عندما تكون هذه الوظيفة هي الميزة المدفوعة الوحيدة التي أحتاجها حقًا.
لحسن الحظ، اتضح أنه يمكنك ببساطة حذف الملفات من دليل ذاكرة التخزين المؤقت بنفسك وسيقوم NGINX بالتقاط هذه المشكلة وجلب نسخة جديدة من الواجهة الخلفية دون أي مشكلة. ومع ذلك، إذا قمت بذلك دون تعديل التكوين الخاص بك، فمن المحتمل أن ترى مجموعة كاملة من الرسائل المشابهة لهذه الرسالة في سجل الأخطاء الخاص بك بعد فترة:
يبدو أن هذه الأخطاء تحدث عندما يحاول NGINX نفسه حذف إدخالات ذاكرة التخزين المؤقت بعد الوقت المحدد بواسطة المعلمة غير النشطة لتعليمة fastcgi_cache_path . الإعداد الافتراضي لهذا هو 10 دقائق فقط، ولكن يمكنك تعيينه على أي قيمة تريدها. إذا قمت بتعيينه على، على سبيل المثال، 10 سنوات، فمن غير المحتمل أن تكون لم تقم بإعادة تشغيل الخادم في غضون ذلك الوقت، وبالتالي فإن مؤشر المفتاح في الذاكرة قد تم مسحه في غضون ذلك الوقت. إذا قمت بذلك، فهل تحتاج إلى التأكد من مسح ذاكرة التخزين المؤقت بنفسك، فلن يقوم NGINX بذلك نيابة عنك بعد الآن.
أجد أنه من الغريب حقًا اعتبار عدم إمكانية حذف إدخال ذاكرة التخزين المؤقت لأنه غير موجود خطأً حرجًا . وحقيقة أن تصنيف شدته مرتفع للغاية يعني أنه من المستحيل التخلص منه بمجرد تجاهل إدخالات السجل التي تقل عن حد معين. وبمجرد جلب نسخة جديدة من الواجهة الخلفية، سيوجد الإدخال مرة أخرى، لذا يجب أن يكون هذا بمثابة تحذير على الأكثر، في رأيي.
الآن، إذا لم يكن من الممكن حذف إدخال ذاكرة التخزين المؤقت بسبب مشاكل في الأذونات أو شيء ثالث، فسيكون ذلك خطأً فادحًا، لأنه قد يجعل NGINX يستمر في تقديم المحتوى المخزن مؤقتًا لفترة طويلة بعد وقت انتهاء صلاحيته، ولكن يبدو أن عملية التنظيف لا تجعل هذا التمييز.