NGINX-i vahemälu kustutamine lisab vealogi kriitilised lahtiühendamisvead
Avaldatud: 15. veebruar 2025, kell 11:24:01 UTC
Selles artiklis selgitatakse, kuidas NGINX-i vahemälust üksusi kustutada, ilma et logifailid oleksid tõrketeadetega segamini. Kuigi see ei ole üldiselt soovitatav lähenemisviis, võib see mõnel servajuhtumil kasulik olla.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Selles postituses olev teave põhineb FastCGI vahemällu salvestamisel NGINX 1.4.6-s, mis töötab Ubuntu Server 14.04 x64. See võib teiste versioonide jaoks kehtida, kuid ei pruugi kehtida.
(Värskendus 2025: Algse postituse kirjutamise ja praeguse vahelise aja jooksul on palju muutunud. Serverid on kiiremad ja odavamad, nii et ma tegelikult ei soovitaks selles postituses kirjeldatud lähenemist, kus proovin vahemälu aegumist mikrohaldada, et salvestada paar põlvkonda dünaamilist sisu. Jätan sisu siia edaspidiseks viitamiseks ja juhuks, kui keegi seda ING-d ei vaja mingil põhjusel, ei ole see INX-i praegune versioon siiski vaja. kuigi, aga ma arvan, et teeb).
Pärast mitme saidi üleviimist Apache'ilt NGINX-ile olen hakanud väga kiinduma selle sisseehitatud vahemällu salvestamise võimalustesse, mis töötab enamikul juhtudel väga hästi, ilma minu sekkumiseta.
Ühe saidi puhul vajasin aga tõesti võimalust vahemälu ise tühjendada (nii täielikult kui ka üksikuid kirjeid eemaldada). NGINX-i tasuta kogukonnaväljaanne toetab ainult ajapõhist vahemälu aegumist (st saate selle seadistada kontrollima, kas tunni, päeva vms pärast on midagi muutunud). Aga mis siis, kui puudub usaldusväärne viis varakult kindlaks teha, millal teatud ressurss muutub? Näiteks pole mul õrna aimugi, kas kulub tund, päev või aasta, enne kui ma tagasi tulen ja selles postituses midagi muudan – ja miks ainult tund aega vahemällu salvestada, kui päev vahemällu oleks sobinud?
Siin on vaja vahemälu käsitsi tühjendamise võimalust (või lasta oma veebirakendusel NGINX-i teavitada, et midagi tuleks tühjendada). NGINX-i taga olevad inimesed on selle vajadusest selgelt teadlikud, kuna seda funktsiooni toetatakse nende toote tasulises versioonis – kuid kuigi neil on kindlasti õigus oma litsentse mis tahes viisil seadistada, on hind minu jaoks pisut kõrge, kui see funktsioon on ainus tasuline funktsioon, mida ma tõesti vajan.
Õnneks selgub, et saate lihtsalt vahemälu kataloogist faile ise kustutada ja NGINX võtab selle üles ja toob teie taustast ilma probleemideta uue koopia. Kui teete seda aga konfiguratsiooni muutmata, näete mõne aja pärast tõenäoliselt oma vealogis tervet hulka sellele sarnaseid sõnumeid:
Näib, et need tõrked ilmnevad siis, kui NGINX ise üritab vahemälu kirjeid kustutada pärast seda, kui on määratud aeg, mis on määratud kiircgi_cache_path direktiivi passiivse parameetriga. Vaikimisi on see ainult 10 minutit, kuid saate määrata selle mis tahes väärtusele. Kui seate selle näiteks 10 aastaks, on tõenäoliselt ebatõenäoline, et te pole vahepeal serverit taaskäivitanud, nii et mälus olev võtmeindeks oleks vahepeal kustutatud. Kui teete seda, kas peate veenduma, et tühjendate vahemälu ise, NGINX ei tee seda enam teie eest.
Minu arvates on väga kummaline, et vahemälu kirjet ei saa kustutada, kuna seda pole olemas, peetakse kriitiliseks veaks. Asjaolu, et selle raskusastme klassifikatsioon on nii kõrge, tähendab, et sellest on võimatu vabaneda, kui ignoreerida logikirjeid, mis jäävad alla teatud läve. Niipea, kui taustast tuuakse uus koopia, on kirje uuesti olemas, nii et see peaks minu arvates olema maksimaalselt hoiatus.
Kui vahemälu kirjet ei õnnestunud lubadega seotud probleemide või millegi kolmanda tõttu kustutada, oleks see kriitiline viga, sest see võib panna NGINXi jätkama vahemällu salvestatud sisu teenindamist kaua pärast selle aegumisaega, kuid puhastusprotsess ei paista seda eristavat.