Brisanje NGINX predmemorije stavlja kritične pogreške prekida veze u zapisnik pogrešaka
Objavljeno: 15. veljače 2025. u 11:27:02 UTC
Ovaj članak objašnjava kako izbrisati stavke iz predmemorije NGINX-a, a da vaše datoteke dnevnika nisu pretrpane porukama o pogreškama. Iako općenito nije preporučeni pristup, može biti koristan u nekim rubnim slučajevima.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Informacije u ovom postu temelje se na FastCGI predmemoriranju na NGINX 1.4.6 koji radi na Ubuntu Serveru 14.04 x64. Može, ali i ne mora vrijediti za druge verzije.
(Ažuriranje 2025.: u vremenu između mog pisanja izvornog posta i sada, puno se toga promijenilo. Poslužitelji su brži i jeftiniji, tako da zapravo ne bih preporučio pristup opisan u ovom postu gdje pokušavam mikro-upravljati istekom predmemorije samo da uštedim nekoliko dodatnih generacija dinamičkog sadržaja. Ostaviću sadržaj ovdje za buduću referencu i u slučaju da nekome zaista zatreba iz bilo kojeg razloga. Nisam potvrdio da ovo i dalje radi za trenutne verzije NGINX, doduše, ali mislim da jest).
Nakon migracije nekoliko stranica s Apachea na NGINX, jako su mi se svidjele njegove ugrađene mogućnosti predmemoriranja, koje rade izuzetno dobro u većini okolnosti bez mog punog uplitanja.
Međutim, za jedno od mjesta stvarno mi je trebala mogućnost da sam izbrišem predmemoriju (u potpunosti i uklonite pojedinačne unose). Besplatno izdanje zajednice NGINX-a podržava samo istek predmemorije temeljen na vremenu (tj. možete ga postaviti da provjerava je li se nešto promijenilo nakon sat vremena, dana itd.). Ali što ako ne postoji pouzdan način da se unaprijed odredi kada će se određeni resurs promijeniti? Na primjer, nemam pojma hoće li proći sat, dan ili godina prije nego što se vratim i uredim nešto u ovom postu – i zašto predmemorirati samo jedan sat ako bi predmemoriranje jednog dana bilo u redu?
Ovdje je potrebna mogućnost ručnog brisanja predmemorije (ili tako da vaša web aplikacija obavijesti NGINX da nešto treba očistiti). Ljudi koji stoje iza NGINX-a očito su svjesni potrebe za ovim jer je značajka podržana u plaćenoj verziji njihovog proizvoda – ali iako svakako imaju pravo postaviti svoje licenciranje kako god žele, cijena je za mene malo visoka kada je ova funkcija jedina plaćena značajka koja mi stvarno treba.
Srećom, ispostavilo se da možete sami izbrisati datoteke iz direktorija predmemorije, a NGINX će to shvatiti i bez problema dohvatiti novu kopiju iz vašeg back-enda. Međutim, ako to učinite bez podešavanja konfiguracije, vjerojatno ćete nakon nekog vremena vidjeti čitavu hrpu poruka sličnih ovoj u svom zapisniku pogrešaka:
Čini se da se ove pogreške pojavljuju kada sam NGINX pokuša izbrisati unose predmemorije nakon vremena određenog neaktivnim parametrom direktive fastcgi_cache_path . Zadano je samo 10 minuta, ali možete ga postaviti na bilo koju vrijednost. Ako ga postavite na, recimo, 10 godina, vjerojatno je malo vjerojatno da u međuvremenu niste ponovno pokrenuli poslužitelj tako da bi se indeks ključa u memoriji u međuvremenu obrisao. Ako to učinite, trebate li sami očistiti predmemoriju, NGINX to više neće raditi umjesto vas.
Zaista mi je čudno da se kritičnom pogreškom smatra da se unos u predmemoriju ne može izbrisati jer ne postoji. Činjenica da je njegova klasifikacija ozbiljnosti tako visoka znači da ga se nemoguće riješiti samo ignoriranjem unosa u dnevnik ispod određenog praga. Čim se nova kopija dohvati iz back-enda, unos će ponovno postojati, tako da bi ovo trebalo biti najviše upozorenje, po mom mišljenju.
Sad, ako se unos predmemorije ne može izbrisati zbog problema s dopuštenjima ili nečeg trećeg, to bi bila kritična pogreška, jer bi mogla natjerati NGINX da nastavi posluživati predmemorirani sadržaj dugo nakon isteka vremena, ali čini se da proces čišćenja ne pravi tu razliku.