Om du tar bort NGINX-cache placeras kritiska bortlänkningsfel i felloggen
Publicerad: 15 februari 2025 kl. 11:24:57 UTC
Den här artikeln förklarar hur du tar bort objekt från NGINX:s cache utan att dina loggfiler är belamrade med felmeddelanden. Även om det i allmänhet inte är ett rekommenderat tillvägagångssätt, kan det vara användbart i vissa edge-fall.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Informationen i det här inlägget är baserad på FastCGI-cachelagring på NGINX 1.4.6 som körs på Ubuntu Server 14.04 x64. Det kan eller kanske inte är giltigt för andra versioner.
(Uppdatering 2025: Under tiden mellan jag skrev det ursprungliga inlägget och nu har mycket förändrats. Servrarna är snabbare och billigare, så jag skulle faktiskt inte rekommendera metoden som beskrivs i det här inlägget där jag försöker mikrohantera cache-förfallodatum bara för att spara några extra generationer av dynamiskt innehåll. Jag lämnar innehållet här för framtida referens och ifall någon faktiskt behöver det av vilken anledning som helst av den aktuella versionen av IN har jag fortfarande inte fungerar. dock, men jag skulle tro att det gör det).
Efter att ha migrerat flera sajter från Apache till NGINX har jag blivit väldigt förtjust i dess inbyggda cachingfunktioner, som fungerar extremt bra under de flesta omständigheter utan att jag har så mycket inblandning.
Men för en av webbplatserna behövde jag verkligen möjligheten att rensa cachen (både helt och ta bort enskilda poster) själv. Den kostnadsfria community-utgåvan av NGINX stöder endast tidsbaserat cacheförfall (dvs. du kan ställa in det för att kontrollera om något har ändrats efter en timme, en dag, etc.). Men vad händer om det inte finns något tillförlitligt sätt att i förväg avgöra när en viss resurs kommer att förändras? Jag har till exempel ingen aning om om det kommer att ta en timme, en dag eller ett år innan jag kommer tillbaka och redigerar något i det här inlägget – och varför bara cache i en timme om cachning för en dag hade varit bra?
Det är här möjligheten att rensa cachen manuellt (eller genom att din webbapplikation meddelar NGINX att något ska rensas) behövs. Personerna bakom NGINX är helt klart medvetna om behovet av detta eftersom funktionen stöds i den betalda versionen av deras produkt – men även om de verkligen har rätt att ställa in sin licensiering som de vill, är priset lite högt för mig när denna funktion är den enda betalda funktionen jag verkligen behöver.
Lyckligtvis visar det sig att du bara kan ta bort filer från cachekatalogen själv och NGINX tar upp detta och hämtar en ny kopia från din back-end utan problem. Men om du gör detta utan att justera din konfiguration kommer du sannolikt att se en hel massa meddelanden som liknar detta i din fellogg efter ett tag:
Det verkar som om dessa fel uppstår när NGINX själv försöker ta bort cacheposter efter den tid som anges av den inaktiva parametern i fastcgi_cache_path -direktivet. Standard för detta är bara 10 minuter, men du kan ställa in det till vilket värde du vill. Om du ställer in den på, säg, 10 år, är det förmodligen osannolikt att du inte har startat om servern under tiden så nyckelindexet i minnet skulle ha rensats under tiden. Om du gör detta, måste du se till att du rensar cachen själv, NGINX kommer inte längre att göra det åt dig.
Jag tycker att det är riktigt konstigt att det anses vara ett kritiskt fel att en cache-post inte kan raderas eftersom den inte finns. Det faktum att dess allvarlighetsklassificering är så hög betyder att den är omöjlig att bli av med bara genom att ignorera loggposter under en viss tröskel. Så fort en ny kopia hämtas från back-end kommer posten att existera igen, så detta borde vara en varning på sin höjd, enligt mig.
Om cache-posten nu inte kunde raderas på grund av problem med behörigheter eller något tredje, skulle det vara ett kritiskt fel, eftersom det kan få NGINX att fortsätta visa cachelagrat innehåll långt efter dess utgångstid, men rensningsprocessen verkar inte göra denna skillnad.