NGINX Önbelleğini Silmek Kritik Bağlantı Kaldırma Hatalarını Hata Günlüğüne Koyar
Yayınlandı: 15 Şubat 2025 11:24:58 UTC
Bu makale, günlük dosyalarınızın hata mesajlarıyla karışmasına neden olmadan öğelerin NGINX'in önbelleğinden nasıl silineceğini açıklar. Genellikle önerilen bir yaklaşım olmasa da, bazı uç durumlarda yararlı olabilir.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Bu gönderideki bilgiler Ubuntu Server 14.04 x64 üzerinde çalışan NGINX 1.4.6'daki FastCGI önbelleğe almaya dayanmaktadır. Diğer sürümler için geçerli olabilir veya olmayabilir.
(2025 Güncellemesi: Orijinal yazıyı yazdığım zamandan bu yana çok şey değişti. Sunucular daha hızlı ve daha ucuz, bu yüzden aslında bu yazıda açıklanan, sadece birkaç ekstra dinamik içerik neslini kurtarmak için önbellek süresinin dolmasını mikro yönetmeye çalıştığım yaklaşımı önermiyorum. İçeriği burada gelecekte referans olması ve herhangi bir nedenle birinin gerçekten ihtiyacı olması durumunda kullanmak üzere bırakacağım. Bunun NGINX'in güncel sürümleri için hala işe yarayıp yaramadığını doğrulamadım, ancak işe yaradığını düşünüyorum).
Apache'den NGINX'e birkaç siteyi taşıdıktan sonra, benim pek fazla müdahalem olmadan çoğu durumda gayet iyi çalışan yerleşik önbelleğe alma yeteneklerini çok sevmeye başladım.
Ancak sitelerden biri için önbelleği kendim temizleme (hem tamamen hem de tek tek girdileri kaldırma) yeteneğine gerçekten ihtiyacım vardı. NGINX'in ücretsiz topluluk sürümü yalnızca zamana dayalı önbellek son kullanma tarihini destekler (yani bir şeyin bir saat, bir gün vb. sonra değişip değişmediğini kontrol edecek şekilde ayarlayabilirsiniz). Peki ya belirli bir kaynağın ne zaman değişeceğini önceden belirlemenin güvenilir bir yolu yoksa? Örneğin, bu gönderide bir şeyi geri dönüp düzenlemem için bir saat, bir gün veya bir yıl geçmesi gerekip gerekmediğini bilmiyorum - ve bir gün önbelleğe almak sorun olmayacaksa neden yalnızca bir saat önbelleğe alıyorum?
Önbelleği manuel olarak temizleme (veya web uygulamanızın NGINX'e bir şeyin temizlenmesi gerektiğini bildirmesini sağlama) yeteneğinin gerekli olduğu yer burasıdır. NGINX'in arkasındaki kişiler, bu özelliğin ürünlerinin ücretli sürümünde desteklendiği için bunun gerekliliğinin açıkça farkındadır - ancak lisanslamalarını istedikleri şekilde ayarlamaya kesinlikle hakları olsa da, bu işlev gerçekten ihtiyaç duyduğum tek ücretli özellik olduğunda fiyat benim için biraz yüksek.
Neyse ki, dosyaları önbellek dizininden kendiniz silebileceğiniz ve NGINX'in bunu fark edip sorunsuz bir şekilde arka uçtan yeni bir kopya alabileceği ortaya çıktı. Ancak, bunu yapılandırmanızı değiştirmeden yaparsanız, bir süre sonra hata günlüğünüzde buna benzer bir sürü mesaj görmeniz muhtemeldir:
Bu hataların, NGINX'in fastcgi_cache_path yönergesinin inactive parametresi tarafından belirtilen süreden sonra önbellek girişlerini silmeye çalıştığında meydana geldiği anlaşılıyor. Bunun için varsayılan değer yalnızca 10 dakikadır, ancak bunu istediğiniz değere ayarlayabilirsiniz. Örneğin, 10 yıla ayarlarsanız, bu arada sunucuyu yeniden başlatmamış olmanız olası değildir, bu nedenle bellekteki anahtar dizini bu arada temizlenmiş olur. Bunu yaparsanız, önbelleği kendiniz temizlediğinizden emin olmanız gerekir, NGINX artık bunu sizin için yapmayacaktır.
Bir önbellek girişinin silinememesinin kritik bir hata olarak kabul edilmesini gerçekten garip buluyorum çünkü var değil. Ciddiyet sınıflandırmasının çok yüksek olması, belirli bir eşiğin altındaki günlük girişlerini görmezden gelerek kurtulmanın imkansız olduğu anlamına geliyor. Arka uçtan yeni bir kopya getirilir getirilmez giriş tekrar var olacak, bu yüzden bence bu en fazla bir uyarı olmalı.
Şimdi, önbellek girişi izinlerle ilgili sorunlar veya üçüncü bir sebepten dolayı silinemiyorsa, bu kritik bir hata olur, çünkü bu durumda NGINX önbelleğe alınmış içeriği son kullanma tarihinden uzun süre sonra bile sunmaya devam edebilir, ancak temizleme işlemi bu ayrımı gözetmiyor gibi görünüyor.