Sletting av NGINX-buffer setter kritiske frakoblingsfeil i feilloggen

Informasjonen i dette innlegget er basert på FastCGI-bufring på NGINX 1.4.6 som kjører på Ubuntu Server 14.04 x64. Det kan være gyldig for andre versjoner.

(Oppdatering 2025: I tiden mellom jeg skrev det opprinnelige innlegget og nå, har mye endret seg. Servere er raskere og billigere, så jeg vil faktisk ikke anbefale tilnærmingen beskrevet i dette innlegget der jeg prøver å mikroadministrere cache-utløp bare for å spare noen ekstra generasjoner med dynamisk innhold. Jeg lar innholdet ligge her for fremtidig referanse og i tilfelle noen faktisk trenger det av en eller annen grunn. Jeg har imidlertid ikke bekreftet at dette fortsatt fungerer for nåværende versjoner av NGINX, men jeg vil tro at det gjør det).

Etter å ha migrert flere nettsteder fra Apache til NGINX har jeg blitt veldig glad i de innebygde caching-funksjonene, som fungerer ekstremt bra under de fleste omstendigheter uten mye innblanding fra meg.

Men for et av nettstedene trengte jeg virkelig muligheten til å tømme hurtigbufferen (både helt og fjerne individuelle oppføringer) selv. Den gratis fellesskapsutgaven av NGINX støtter bare tidsbasert cache-utløp (dvs. du kan sette den opp for å sjekke om noe har endret seg etter en time, en dag osv.). Men hva om det ikke er noen pålitelig måte å bestemme på forhånd når en bestemt ressurs vil endres? For eksempel aner jeg ikke om det vil ta en time, en dag eller et år før jeg kommer tilbake og redigerer noe i dette innlegget – og hvorfor bare cache i en time hvis caching for en dag hadde vært greit?

Det er her muligheten til å tømme hurtigbufferen manuelt (eller ved å få nettapplikasjonen til å varsle NGINX om at noe bør slettes) er nødvendig. Folkene bak NGINX er tydelig klar over behovet for dette ettersom funksjonen støttes i den betalte versjonen av produktet deres – men selv om de absolutt har rett til å sette opp lisensiering slik de vil, er prisen litt høy for meg når denne funksjonen er den eneste betalte funksjonen jeg virkelig trenger.

Heldigvis viser det seg at du bare kan slette filer fra cache-katalogen selv, og NGINX vil plukke opp dette og hente en ny kopi fra back-end uten problemer. Men hvis du gjør dette uten å justere konfigurasjonen, vil du sannsynligvis se en hel haug med meldinger som ligner på denne i feilloggen din etter en stund:

Det ser ut til at disse feilene oppstår når NGINX selv prøver å slette cache-oppføringer etter tiden spesifisert av den inaktive parameteren til fastcgi_cache_path-direktivet . Standard for dette er bare 10 minutter, men du kan sette den til hvilken verdi du vil. Hvis du setter den til for eksempel 10 år, er det sannsynligvis usannsynlig at du ikke har startet serveren på nytt i mellomtiden, så nøkkelindeksen i minnet ville ha blitt slettet i mellomtiden. Hvis du gjør dette, må du sørge for at du tømmer hurtigbufferen selv, NGINX vil ikke lenger gjøre det for deg.

Jeg synes det er veldig rart at det anses som en kritisk feil at en cache-oppføring ikke kan slettes fordi den ikke eksisterer. Det faktum at alvorlighetsgradsklassifiseringen er så høy, betyr at det er umulig å bli kvitt bare ved å ignorere loggoppføringer under en viss terskel. Så snart en ny kopi er hentet fra back-end vil oppføringen eksistere igjen, så dette bør være en advarsel på det meste, etter min mening.

Nå, hvis cache-oppføringen ikke kunne slettes på grunn av problemer med tillatelser eller noe tredje, ville det være en kritisk feil, fordi det kan få NGINX til å fortsette å servere bufret innhold lenge etter utløpstiden, men oppryddingsprosessen ser ikke ut til å gjøre dette skillet.