Ștergerea cache-ului NGINX pune erori critice de deconectare în jurnalul de erori

Publicat: 15 februarie 2025 la 11:24:43 UTC

Acest articol explică cum să ștergeți elemente din memoria cache a NGINX fără a avea fișierele jurnal aglomerate cu mesaje de eroare. Deși în general nu este o abordare recomandată, poate fi utilă în unele cazuri marginale.

Această pagină a fost tradusă automat din limba engleză pentru a o face accesibilă cât mai multor persoane. Din păcate, traducerea automată nu este încă o tehnologie perfecționată, astfel încât pot apărea erori. Dacă preferați, puteți vizualiza versiunea originală în limba engleză aici:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Informațiile din această postare se bazează pe memoria cache FastCGI pe NGINX 1.4.6 care rulează pe Ubuntu Server 14.04 x64. Poate fi valabil sau nu pentru alte versiuni.

(Actualizare 2025: În intervalul dintre am scris postarea originală și acum, multe s-au schimbat. Serverele sunt mai rapide și mai ieftine, așa că, de fapt, nu aș recomanda abordarea descrisă în această postare în care încerc să micro-gestionez expirarea cache-ului doar pentru a salva câteva generații în plus de conținut dinamic. Voi lăsa conținutul aici pentru referințe viitoare și în cazul în care cineva chiar are nevoie de ea pentru că încă nu are nevoie de această versiune pentru orice motiv. NGINX, totuși, dar aș crede că da).

După ce am migrat mai multe site-uri de la Apache la NGINX, m-am îndrăgostit foarte mult de capacitățile sale de stocare în cache încorporate, care funcționează extrem de bine în majoritatea circumstanțelor, fără să mă amestec prea mult din partea mea.

Cu toate acestea, pentru unul dintre site-uri, chiar aveam nevoie de capacitatea de a șterge cache-ul (atât complet, cât și de a elimina intrările individuale). Ediția gratuită a comunității NGINX acceptă doar expirarea cache-ului bazată pe timp (adică o puteți configura pentru a verifica dacă ceva s-a schimbat după o oră, o zi etc.). Dar ce se întâmplă dacă nu există o modalitate fiabilă de a determina dinainte când se va schimba o anumită resursă? De exemplu, habar n-am dacă va trece o oră, o zi sau un an până când mă întorc și editez ceva în această postare – și de ce să păstrez în cache doar o oră dacă memorarea în cache pentru o zi ar fi fost bine?

Aici este nevoie de capacitatea de a șterge cache-ul manual (sau de a solicita aplicației dvs. web să notifice NGINX că ceva ar trebui să fie curățat). Oamenii din spatele NGINX sunt în mod clar conștienți de necesitatea acestui lucru, deoarece caracteristica este acceptată în versiunea plătită a produsului lor – dar, deși cu siguranță au dreptul să își configureze licențele în orice mod doresc, prețul este puțin cam mare pentru mine când această funcție este singura caracteristică plătită de care am nevoie cu adevărat.

Din fericire, se pare că puteți șterge singur fișierele din directorul cache, iar NGINX va prelua acest lucru și va prelua o nouă copie din back-end fără probleme. Cu toate acestea, dacă faceți acest lucru fără a modifica configurația, este posibil să vedeți o mulțime de mesaje similare cu acesta în jurnalul de erori după un timp:

2015/03/04 17:35:24 [crit] 16665#0: unlink() \"/path/to/nginx/cache/9/a0/53eb903773998c16dcc570e6daebda09\" failed (2: No such file or directory)

Se pare că aceste erori apar atunci când NGINX însuși încearcă să ștergă intrările din cache după timpul specificat de parametrul inactiv al directivei fastcgi_cache_path . Valoarea implicită pentru aceasta este de numai 10 minute, dar o puteți seta la orice valoare doriți. Dacă îl setați la, să zicem, 10 ani, probabil că este puțin probabil să nu fi repornit serverul între timp, astfel încât indexul cheii din memorie ar fi fost șters între timp. Dacă faceți acest lucru, trebuie să vă asigurați că ștergeți singur memoria cache, NGINX nu o va mai face în locul dvs.

Mi se pare cu adevărat ciudat că este considerat o eroare critică faptul că o intrare din cache nu poate fi ștearsă deoarece nu există. Faptul că clasificarea sa de severitate este atât de mare înseamnă că este imposibil să scapi de el doar ignorând intrările de jurnal sub un anumit prag. De îndată ce o copie nouă este preluată din back-end, intrarea va exista din nou, așa că acesta ar trebui să fie cel mult un avertisment, în opinia mea.

Acum, dacă intrarea în cache nu a putut fi ștearsă din cauza unor probleme cu permisiunile sau ceva a treia, aceasta ar fi o eroare critică, deoarece ar putea face ca NGINX să continue să difuzeze conținut în cache mult după expirarea sa, dar procesul de curățare nu pare să facă această distincție.