Brisanje predpomnilnika NGINX vnese kritične napake pri prekinitvi povezave v dnevnik napak
Objavljeno: 15. februar 2025 ob 11:24:56 dop. UTC
Ta članek pojasnjuje, kako izbrisati elemente iz predpomnilnika NGINX, ne da bi bile vaše dnevniške datoteke zatrpane s sporočili o napakah. Čeprav na splošno ni priporočljiv pristop, je lahko uporaben v nekaterih robnih primerih.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Informacije v tej objavi temeljijo na predpomnjenju FastCGI na NGINX 1.4.6, ki se izvaja na Ubuntu Server 14.04 x64. Lahko velja ali ne velja za druge različice.
(Posodobitev 2025: V času med pisanjem prvotne objave in zdaj se je marsikaj spremenilo. Strežniki so hitrejši in cenejši, zato pravzaprav ne priporočam pristopa, opisanega v tej objavi, kjer poskušam mikro upravljati potek predpomnilnika samo zato, da prihranim nekaj dodatnih generacij dinamične vsebine. Vsebino bom pustil tukaj za prihodnjo uporabo in v primeru, da jo bo kdo iz kakršnega koli razloga dejansko potreboval. Nisem potrdil, da to še vedno deluje za trenutne različice NGINX, vendar mislim, da je).
Po selitvi več spletnih mest z Apache na NGINX so mi postale zelo všeč njegove vgrajene zmožnosti predpomnjenja, ki delujejo izjemno dobro v večini okoliščin, brez mojega velikega vmešavanja.
Vendar sem za eno od spletnih mest resnično potreboval možnost, da sam počistim predpomnilnik (tako v celoti kot odstranitve posameznih vnosov). Brezplačna skupnostna izdaja NGINX podpira samo časovni potek predpomnilnika (tj. nastavite ga lahko tako, da preveri, ali se je kaj spremenilo po eni uri, dnevu itd.). Kaj pa, če ni zanesljivega načina, da bi vnaprej določili, kdaj se bo določen vir spremenil? Na primer, nimam pojma, ali bo minila ena ura, dan ali leto, preden se vrnem in nekaj uredim v tej objavi – in zakaj bi predpomnil samo eno uro, če bi bilo predpomnjenje za en dan v redu?
Tu je potrebna možnost ročnega čiščenja predpomnilnika (ali tako, da vaša spletna aplikacija obvesti NGINX, da je treba nekaj počistiti). Ljudje, ki stojijo za NGINX, se očitno zavedajo potrebe po tem, saj je funkcija podprta v plačljivi različici njihovega izdelka – toda čeprav so zagotovo upravičeni nastaviti svoje licenciranje, kakor hočejo, je cena zame nekoliko visoka, saj je ta funkcija edina plačljiva funkcija, ki jo resnično potrebujem.
Na srečo se je izkazalo, da lahko datoteke iz imenika predpomnilnika enostavno izbrišete sami in NGINX bo to ugotovil in brez težav pridobil novo kopijo iz vašega zaledja. Vendar, če to storite, ne da bi prilagodili svojo konfiguracijo, boste verjetno čez nekaj časa videli cel kup sporočil, podobnih temu v dnevniku napak:
Zdi se, da se te napake pojavijo, ko NGINX sam poskuša izbrisati vnose v predpomnilnik po času, določenem z neaktivnim parametrom direktive fastcgi_cache_path . Privzeta vrednost za to je samo 10 minut, vendar jo lahko nastavite na poljubno vrednost. Če ga nastavite na, recimo, 10 let, je verjetno malo verjetno, da medtem niste znova zagnali strežnika, tako da bi bil indeks ključev v pomnilniku medtem počiščen. Če to storite, se morate prepričati , da sami počistite predpomnilnik, NGINX tega ne bo več naredil namesto vas.
Zelo čudno se mi zdi, da se šteje za kritično napako, da vnosa v predpomnilnik ni mogoče izbrisati, ker ne obstaja. Dejstvo, da je njegova klasifikacija resnosti tako visoka, pomeni, da se je nemogoče znebiti samo z ignoriranjem vnosov v dnevnik pod določenim pragom. Takoj, ko je nova kopija pridobljena iz ozadja, bo vnos spet obstajal, tako da bi to moralo biti po mojem mnenju kvečjemu opozorilo.
Zdaj, če vnosa v predpomnilnik ni bilo mogoče izbrisati zaradi težav z dovoljenji ali česa tretjega, bi bila to kritična napaka, ker bi lahko povzročilo, da NGINX še dolgo po izteku časa streže predpomnjeno vsebino, vendar se zdi, da postopek čiščenja ne naredi te razlike.