Brisanje NGINX keša stavlja kritične greške u dnevniku grešaka
Objavio: 19. mart 2025. 21:28:22 UTC
Ovaj članak objašnjava kako da izbrišete stavke iz NGINKS-ovog keša bez da vaše datoteke dnevnika budu pretrpane porukama o greškama. Iako generalno nije preporučeni pristup, može biti korisno u nekim rubnim slučajevima.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Informacije u ovom postu bazirane su na FastCGI keširanju na NGINX 1.4.6 koji radi na Ubuntu Server 14.04 x64. Može biti tačno ili ne važno za druge verzije.
(Ažuriranje 2025: U vremenu između kada sam napisao originalni post i sada, mnogo se toga promenilo. Serveri su brži i jeftiniji, pa zapravo ne bih preporučio pristup opisan u ovom postu gde pokušavam mikroupravljati istekom keša samo da bih uštedeo nekoliko dodatnih generacija dinamičkog sadržaja. Ostavio sam sadržaj ovde za buduću referencu i u slučaju da neko zaista treba ovo iz bilo kog razloga. Nisam potvrdio da ovo još uvek radi za trenutne verzije NGINX-a, međutim, mislim da bi trebalo).
Nakon migracije nekoliko sajtova sa Apache na NGINX, veoma sam se zbližio sa njegovim ugrađenim mogućnostima keširanja, koje funkcionišu izuzetno dobro u većini okolnosti bez mnogo mog mešanja.
Međutim, za jedan od sajtova, stvarno mi je bila potrebna mogućnost da sam očistim keš (i potpuno i da uklonim pojedinačne stavke). Besplatna zajednička verzija NGINX-a podržava samo keširanje zasnovano na vremenu (tj. možete ga postaviti da proveri da li se nešto promenilo nakon sat vremena, dana, itd.). Ali šta ako ne postoji pouzdan način da se unapred odredi kada će se neki resurs promeniti? Na primer, nemam pojma da li će to biti za sat, dan ili godinu dana pre nego što se vratim i izmenim nešto u ovom postu – i zašto keširati samo sat ako bi keširanje za dan bilo u redu?
Ovdje je potrebna mogućnost da se keš ručno očisti (ili tako što vaša web aplikacija obavesti NGINX da nešto treba da se izbriše). Ljudi iza NGINX-a su očigledno svesni potrebe za ovim, jer je ova funkcija podržana u plaćenoj verziji njihovog proizvoda – ali iako oni imaju pravo da postave licenciranje kako žele, cena je za mene malo visoka kada je ova funkcija jedina plaćena funkcionalnost koja mi zaista treba.
Na sreću, ispostavlja se da možete sami izbrisati fajlove iz direktorijuma keša i NGINX će to primetiti i preuzeti novu kopiju sa vašeg back-end-a bez problema. Međutim, ako to uradite bez podešavanja vaše konfiguracije, verovatno ćete nakon nekog vremena videti gomilu poruka sličnih ovoj u vašem logu grešaka:
Čini se da ove greške nastaju kada sam NGINX pokušava da obriše stavke iz keša nakon vremena koje je postavljeno parametrom inactive direktive fastcgi_cache_path. Podrazumevano je ovo samo 10 minuta, ali možete ga postaviti na bilo koju vrednost koju želite. Ako ga postavite na, recimo, 10 godina, verovatno je malo verovatno da niste restartovali server u međuvremenu, pa će ključni indeks u memoriji biti očišćen. Ako to uradite, morate pobrinuti se da očistite keš sami, NGINX to više neće raditi umesto vas.
Čudno mi je što se smatra kritičnom greškom to što stavka keša ne može biti obrisana jer ne postoji. Činjenica da je klasifikacija ozbiljnosti toliko visoka znači da je nemoguće rešiti to samo ignorisanjem logova ispod određenog praga. Čim nova kopija bude preuzeta sa back-end-a, stavka će ponovo postojati, pa bi ovo trebalo biti samo upozorenje, po mom mišljenju.
Sada, ako stavka keša nije mogla biti obrisana zbog problema sa dozvolama ili nečim trećim, to bi bila kritična greška, jer bi moglo prouzrokovati da NGINX nastavi da servira keširani sadržaj dugo nakon isteka njegovog vremena, ali proces čišćenja se čini da ne pravi ovu razliku.