NGINX कैश को हटाने से त्रुटि लॉग में गंभीर अनलिंक त्रुटियाँ आ जाती हैं
प्रकाशित: 15 फ़रवरी 2025 को 11:25:04 am UTC बजे
यह लेख बताता है कि NGINX के कैश से आइटम कैसे डिलीट करें, बिना आपकी लॉग फ़ाइलों को त्रुटि संदेशों से भरे। हालाँकि यह आम तौर पर अनुशंसित तरीका नहीं है, लेकिन यह कुछ मामलों में उपयोगी हो सकता है।
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
इस पोस्ट में दी गई जानकारी Ubuntu सर्वर 14.04 x64 पर चल रहे NGINX 1.4.6 पर FastCGI कैशिंग पर आधारित है। यह अन्य संस्करणों के लिए मान्य हो भी सकता है और नहीं भी।
(अपडेट 2025: मूल पोस्ट लिखने से लेकर अब तक के समय में बहुत कुछ बदल गया है। सर्वर तेज़ और सस्ते हैं, इसलिए मैं वास्तव में इस पोस्ट में वर्णित दृष्टिकोण की अनुशंसा नहीं करूँगा जहाँ मैं गतिशील सामग्री की कुछ अतिरिक्त पीढ़ियों को बचाने के लिए कैश समाप्ति को माइक्रो-मैनेज करने का प्रयास करता हूँ। मैं भविष्य के संदर्भ के लिए सामग्री को यहाँ छोड़ दूँगा और यदि किसी को वास्तव में किसी भी कारण से इसकी आवश्यकता होती है। मैंने पुष्टि नहीं की है कि यह अभी भी NGINX के वर्तमान संस्करणों के लिए काम करता है, लेकिन मुझे लगता है कि यह करता है)।
कई साइटों को अपाचे से एनजीआईएनएक्स में स्थानांतरित करने के बाद, मुझे इसकी अंतर्निहित कैशिंग क्षमताएं बहुत पसंद आने लगी हैं, जो अधिकांश परिस्थितियों में बिना मेरी ज्यादा दखलंदाजी के बहुत अच्छी तरह से काम करती हैं।
हालाँकि, एक साइट के लिए, मुझे वास्तव में कैश को साफ़ करने की क्षमता की आवश्यकता थी (पूरी तरह से और व्यक्तिगत प्रविष्टियों को हटाने के लिए)। NGINX का मुफ़्त सामुदायिक संस्करण केवल समय-आधारित कैश समाप्ति का समर्थन करता है (यानी आप इसे यह जांचने के लिए सेट कर सकते हैं कि एक घंटे, एक दिन, आदि के बाद कुछ बदल गया है या नहीं)। लेकिन क्या होगा अगर किसी निश्चित संसाधन में बदलाव होने से पहले यह निर्धारित करने का कोई विश्वसनीय तरीका नहीं है? उदाहरण के लिए, मुझे नहीं पता कि इस पोस्ट में कुछ संपादित करने से पहले मुझे एक घंटा, एक दिन या एक साल लगेगा - और अगर एक दिन के लिए कैश करना ठीक होता तो केवल एक घंटे के लिए कैश क्यों?
यहीं पर कैश को मैन्युअल रूप से साफ़ करने की क्षमता की आवश्यकता होती है (या आपके वेब एप्लिकेशन द्वारा NGINX को सूचित करना कि कुछ साफ़ किया जाना चाहिए)। NGINX के पीछे के लोग इसकी आवश्यकता के बारे में स्पष्ट रूप से जानते हैं क्योंकि यह सुविधा उनके उत्पाद के सशुल्क संस्करण में समर्थित है - लेकिन जबकि वे निश्चित रूप से अपने लाइसेंसिंग को किसी भी तरह से सेट करने के हकदार हैं, मेरे लिए कीमत थोड़ी अधिक है जब यह फ़ंक्शन एकमात्र सशुल्क सुविधा है जिसकी मुझे वास्तव में आवश्यकता है।
सौभाग्य से, यह पता चला है कि आप कैश निर्देशिका से फ़ाइलों को स्वयं हटा सकते हैं और NGINX इसे उठाएगा और बिना किसी रुकावट के आपके बैक-एंड से एक नई कॉपी प्राप्त करेगा। हालाँकि, यदि आप अपने कॉन्फ़िगरेशन में बदलाव किए बिना ऐसा करते हैं, तो आपको कुछ समय बाद अपने त्रुटि लॉग में इस तरह के कई संदेश दिखाई देने की संभावना है:
ऐसा प्रतीत होता है कि ये त्रुटियाँ तब होती हैं जब NGINX स्वयं fastcgi_cache_path निर्देश के निष्क्रिय पैरामीटर द्वारा निर्दिष्ट समय के बाद कैश प्रविष्टियों को हटाने का प्रयास करता है। इसके लिए डिफ़ॉल्ट केवल 10 मिनट है, लेकिन आप इसे अपनी इच्छानुसार किसी भी मान पर सेट कर सकते हैं। यदि आप इसे 10 वर्ष पर सेट करते हैं, तो संभवतः यह असंभव है कि आपने इस बीच सर्वर को पुनः आरंभ नहीं किया है, इसलिए इस बीच मेमोरी में कुंजी इंडेक्स साफ़ हो गया होगा। यदि आप ऐसा करते हैं, तो क्या आपको यह सुनिश्चित करने की आवश्यकता है कि आप स्वयं कैश साफ़ करें, NGINX अब आपके लिए ऐसा नहीं करेगा।
मुझे यह वाकई अजीब लगता है कि इसे एक गंभीर त्रुटि माना जाता है कि कैश प्रविष्टि को हटाया नहीं जा सकता क्योंकि यह मौजूद नहीं है। तथ्य यह है कि इसकी गंभीरता वर्गीकरण इतना अधिक है कि एक निश्चित सीमा से नीचे लॉग प्रविष्टियों को अनदेखा करके इससे छुटकारा पाना असंभव है। जैसे ही बैक-एंड से एक नई कॉपी लाई जाती है, प्रविष्टि फिर से मौजूद हो जाएगी, इसलिए मेरी राय में यह ज़्यादा से ज़्यादा एक चेतावनी होनी चाहिए।
अब, यदि अनुमतियों या किसी अन्य कारण से कैश प्रविष्टि को हटाया नहीं जा सका, तो यह एक गंभीर त्रुटि होगी, क्योंकि इससे NGINX कैश की गई सामग्री को उसकी समाप्ति समय के बाद भी लंबे समय तक जारी रख सकता है, लेकिन क्लीन-अप प्रक्रिया यह अंतर नहीं कर पाती है।