NGINX Önbelleği Silinərkən Xəta Qeydi
Nəşr olundu: 15 fevral 2025 at 11:28:26 UTC
Bu məqalədə NGINX-in önbelleğindən olan əşyaları səhv mesajlarla sındırmadan necə silmək lazım olduğu izah olunur. Adətən məsləhət görülən üsul olmasa da, bəzi kənar hallarda faydalı ola bilər.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Bu yazıdakı məlumatlar Ubuntu Server 14.04 x64-də çalışan NGINX 1.4.6-da FastCGI caching əsasında hazırlanıb. Digər versiyalar üçün də keçərli ola bilər və ya olmaya bilər.
(Update 2025: Orijinal yazını yazdığım vaxt və indi çox şey dəyişib. Serverlər daha sürətli və daha ucuzdur. Ona görə də mən əslində bu yazıda təsvir olunan yanaşmanı tövsiyə etməzdim. Burada sadəcə bir neçə əlavə nəsil dinamik məzmun qənaət etmək üçün cache expiry-i mikro idarə etməyə çalışıram. Məzmunu gələcək istinad üçün burada qoyacağam və əgər əslində kimsə hər hansı səbəbdən buna ehtiyac duyursa. Mən təsdiq etmədim ki, bu hələ də NGINX-nin indiki versiyaları üçün işləyir, amma mən düşünərdim ki, belə də olur).
Apache-dən NGINX-ə bir neçə sayt köçürəndən sonra onun inşa edilmiş qəfəs qurma qabiliyyətlərini çox sevirəm. Əksər şəraitlərdə məndən çox qarışmadan son dərəcə yaxşı işləyir.
Bununla belə, saytlardan biri üçün, həqiqətən, özüm də cache-i təmizləmək (həm tam, həm də fərdi girişləri aradan qaldırmaq) bacarığına ehtiyacım var idi. NGINX-in pulsuz icma nəşri yalnız vaxt əsaslı cache expiry dəstəkləyir (yəni bir saat, bir gün və s. sonra bir şey dəyişib-dəyişmədiyi yoxlamaq üçün onu qurmaq olar). Bəs əgər hansısa resursun nə vaxt dəyişəcəyini qabaqcadan müəyyən etmək üçün etibarlı üsul yoxdursa, onda necə? Məsələn, bir saat, bir gün və ya bir il olacaq heç bir fikrim yoxdur ki, geri qayıdıb bu postda bir şey redaktə edim – və niyə yalnız bir saat üçün cache əgər bir gün üçün caach yaxşı olardı?
Burada cache-i əl ilə təmizləmək bacarığı (və ya veb-tətbiqinizin NGINX-ə bir şeyin təmizlənməsi lazım olduğunu bildirməsi ilə) lazımdır. NGINX-in arxasında duran insanlar bu funksiyanın öz məhsulunun ödənişli versiyasında dəstəkləndiyi üçün bunun zəruriliyini aydın şəkildə dərk edirlər – ancaq onlar, əlbəttə ki, lisenziyalarını istədikləri yolla qurmaq hüququna malik olsalar da, bu funksiya mənə həqiqətən lazım olan yeganə ödənişli xüsusiyyət olduğu halda qiymət mənim üçün bir az dikdir.
Xoşbəxtlikdən, məlum olur ki, siz özünüz sadəcə cache directory-dən faylları silə bilərsiniz və NGINX bunun üzərinə götürəcək və hitch olmadan arxanızdan yeni bir nüsxə gətirəcək. Bununla belə, əgər konfiqurasiyanızı tweak etmədən bunu etsəniz, çox güman ki, bir müddət sonra səhv qeydinizdə buna bənzər bir yığın mesaj görəcəksiniz:
Görünür ki, bu səhvlər NGINX özü fastcgi_cache_path göstərişinin qeyri-aktiv parametri ilə müəyyən edilmiş müddətdən sonra cache girişlərini silməyə çalışdığı zaman baş verir. Bunun üçün default cəmi 10 dəqiqədir, amma istədiyiniz qiymətə təyin edə bilərsiniz. Əgər siz onu təyin etsəniz, deyin, 10 il, yəqin ki, bu müddətdə serveri yenidən başlatmamağınız çətin ki, bu müddətdə yaddaşdakı əsas indeks təmizlənəydi. Bunu etsəniz, özünüz cache təmizləmək üçün əmin olmalısınız, NGINX artıq sizin üçün bunu etməyəcək.
Mən həqiqətən qəribə hesab edirəm ki, bir cache giriş mövcud olmadığı üçün silinə bilməz tənqidi bir səhv hesab olunur. Onun ağırlıq klassifikasiyasının bu qədər yüksək olması o deməkdir ki, sadəcə müəyyən bir hədddən aşağı log girişlərinə məhəl qoymayaraq onu qurtarmaq qeyri-mümkündür. Arxa tərəfdən yeni nüsxə gələn kimi giriş yenidən mövcud olacaq. Ona görə də bu, ən çox, mənim fikrimcə, xəbərdarlıq olmalıdır.
İndi, əgər cache girişi icazələr və ya üçüncü bir şey ilə bağlı problemlər səbəbiylə silinə bilmədisə, bu kritik bir xəta olardı, çünki bu, NGINX'in müddəti bitdikdən uzun müddət sonra önbelleğə alınmış məzmuna xidmət etməyə davam edə bilər. Ancaq təmizləmə prosesi bu fərqliliyi sanki etmir.