L'eliminació de la memòria cau NGINX posa errors crítics de desenllaç al registre d'errors

Publicat: 5 de març del 2025, a les 19:30:54 UTC

En aquest article s'explica com esborrar elements de la memòria cau de NGINX sense tenir els fitxers de registre desordenats de missatges d'error. Tot i que generalment no és un enfocament recomanat, pot ser útil en alguns casos extrems.

Aquesta pàgina es va traduir automàticament de l'anglès per tal de fer-la accessible al màxim de persones possible. Malauradament, la traducció automàtica encara no és una tecnologia perfeccionada, de manera que es poden produir errors. Si ho prefereixes, pots veure la versió original en anglès aquí:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

La informació d'aquesta publicació es basa en la memòria cau FastCGI a NGINX 1.4.6 que s'executa a Ubuntu Server 14.04 x64. Pot ser vàlid o no per a altres versions.

(Actualització 2025: entre el temps que vaig escriure la publicació original i ara, moltes coses han canviat. Els servidors són més ràpids i barats, així que, de fet, no recomanaria l'enfocament descrit en aquesta publicació en què intento microgestionar la caducitat de la memòria cau només per estalviar unes quantes generacions addicionals de contingut dinàmic. Deixaré el contingut aquí per a referència futura i en cas que algú realment ho necessiti per alguna raó, encara no ho té confirmat per la versió actual que no funciona. NGINX, però, però crec que sí).

Després de migrar diversos llocs d'Apache a NGINX, m'he aficionat molt a les seves capacitats d'emmagatzematge a la memòria cau integrades, que funciona molt bé en la majoria de les circumstàncies sense intervenir massa per mi.

Tanmateix, per a un dels llocs, realment necessitava la capacitat d'esborrar la memòria cau (tant completament com eliminar entrades individuals) jo mateix. L'edició comunitària gratuïta de NGINX només admet la caducitat de la memòria cau basada en el temps (és a dir, podeu configurar-la per comprovar si alguna cosa ha canviat després d'una hora, un dia, etc.). Però, què passa si no hi ha una manera fiable de determinar amb antelació quan canviarà un determinat recurs? Per exemple, no tinc ni idea de si passarà una hora, un dia o un any abans de tornar i editar alguna cosa en aquesta publicació, i per què només emmagatzema a la memòria cau durant una hora si la memòria cau durant un dia hauria estat bé?

Aquí és on es necessita la capacitat d'esborrar la memòria cau manualment (o fent que la vostra aplicació web notifiqui a NGINX que s'ha de purgar alguna cosa). Les persones que hi ha darrere de NGINX són clarament conscients de la necessitat d'això, ja que la funció s'admet a la versió de pagament del seu producte, però encara que segur que tenen dret a configurar la seva llicència de la manera que vulguin, el preu és una mica elevat per a mi quan aquesta funció és l'única funció de pagament que realment necessito.

Afortunadament, resulta que només podeu suprimir fitxers del directori de memòria cau vosaltres mateixos i NGINX ho recollirà i obtindrà una còpia nova del vostre fons sense cap problema. Tanmateix, si ho feu sense ajustar la vostra configuració, és probable que vegeu un munt de missatges similars a aquest al vostre registre d'errors al cap d'un temps:

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

Sembla que aquests errors es produeixen quan el mateix NGINX intenta suprimir les entrades de la memòria cau després del temps especificat pel paràmetre inactiu de la directiva fastcgi_cache_path . El valor predeterminat és només 10 minuts, però podeu configurar-lo amb el valor que vulgueu. Si ho fixeu en, per exemple, 10 anys, probablement és poc probable que no hàgiu reiniciat el servidor mentrestant, de manera que l'índex clau de la memòria s'hauria esborrat mentrestant. Si feu això, heu d' assegurar -vos d'esborrar la memòria cau vosaltres mateixos, NGINX ja no ho farà per vosaltres.

Em sembla molt estrany que es consideri un error crític que no es pugui suprimir una entrada de memòria cau perquè no existeix. El fet que la seva classificació de gravetat sigui tan alta significa que és impossible desfer-se'n només ignorant les entrades de registre per sota d'un determinat llindar. Tan bon punt s'obté una còpia nova del back-end, l'entrada tornarà a existir, així que això hauria de ser com a molt un avís, al meu entendre.

Ara, si l'entrada de la memòria cau no es pogués suprimir a causa de problemes amb els permisos o alguna cosa tercera, seria un error crític, perquè podria fer que NGINX continués publicant contingut en memòria cau molt després del seu temps de caducitat, però el procés de neteja no sembla fer aquesta distinció.