Az NGINX gyorsítótár törlésével kritikus leválasztási hibák jelennek meg a hibanaplóban

Az ebben a bejegyzésben található információk az Ubuntu Server 14.04 x64 rendszeren futó NGINX 1.4.6-os FastCGI gyorsítótáron alapulnak. Lehet, hogy más verziókra érvényes, de lehet, hogy nem.

(Frissítés 2025: Az eredeti bejegyzés megírása és most között eltelt idő alatt sok minden változott. A szerverek gyorsabbak és olcsóbbak, ezért valójában nem javaslom az ebben a bejegyzésben leírt megközelítést, amikor megpróbálom a gyorsítótár lejáratának mikrokezelését, csak hogy megmentsem néhány további generációnyi dinamikus tartalmat. A tartalmat itt hagyom későbbi hivatkozás céljából, és arra az esetre, ha valakinek valóban szüksége lenne rá, ez az INX verziója még mindig nem működik, bármilyen okból is. bár, de szerintem igen).

Miután több webhelyet áttelepítettem az Apache-ról az NGINX-re, nagyon megszerettem a beépített gyorsítótárazási képességeit, amelyek a legtöbb esetben rendkívül jól működnek anélkül, hogy különösebben beleavatkoznék.

Az egyik webhely esetében azonban valóban szükségem volt a gyorsítótár törlésére (teljesen és az egyes bejegyzések eltávolítására egyaránt). Az NGINX ingyenes közösségi kiadása csak az időalapú gyorsítótár-lejáratot támogatja (azaz beállíthatod, hogy egy óra, egy nap stb. elteltével ellenőrizd, történt-e valami változás). De mi van akkor, ha nincs megbízható módszer annak meghatározására, hogy egy adott erőforrás mikor fog megváltozni? Például fogalmam sincs, hogy egy óra, egy nap vagy egy év telik el, mire visszajövök és szerkesztek valamit ebben a bejegyzésben – és miért csak egy órán át gyorsítótárazok, ha az egy napos gyorsítótár jó lett volna?

Itt van szükség a gyorsítótár kézi törlésének lehetőségére (vagy úgy, hogy a webalkalmazás értesíti az NGINX-et, hogy valamit törölni kell). Az NGINX mögött álló emberek egyértelműen tisztában vannak ennek szükségességével, mivel a funkciót termékük fizetős verziója támogatja – de bár minden bizonnyal joguk van tetszőlegesen beállítani a licencet, az ár számomra kissé borsos, ha ez a funkció az egyetlen fizetős szolgáltatás, amelyre valóban szükségem van.

Szerencsére kiderült, hogy egyszerűen törölheti a fájlokat a gyorsítótár könyvtárából, és az NGINX felveszi ezt, és gond nélkül letölt egy új másolatot a háttérből. Ha azonban ezt a konfiguráció módosítása nélkül teszi meg, egy idő után valószínűleg egy csomó ehhez hasonló üzenetet fog látni a hibanaplójában:

Úgy tűnik, hogy ezek a hibák akkor fordulnak elő, amikor az NGINX maga próbálja meg törölni a gyorsítótár-bejegyzéseket a fastcgi_cache_path direktíva inaktív paramétere által meghatározott idő után. Ennek alapértelmezett értéke csak 10 perc, de tetszőleges értékre állíthatja. Ha mondjuk 10 évre állítod, akkor valószínűleg nem valószínű, hogy közben nem indítottad újra a szervert, így a memóriában lévő kulcsindex időközben törlődött volna. Ha ezt megteszi, meg kell győződnie arról, hogy saját maga törölte a gyorsítótárat, az NGINX többé nem fogja megtenni ezt helyette.

Nagyon furcsállom, hogy kritikus hibának tekintik, hogy a cache bejegyzést nem lehet törölni, mert nem létezik. Az a tény, hogy súlyossági besorolása olyan magas, azt jelenti, hogy lehetetlen megszabadulni tőle, ha figyelmen kívül hagyjuk a naplóbejegyzéseket egy bizonyos küszöbérték alatt. Amint egy új példányt lekérnek a háttérből, a bejegyzés újra meg fog jelenni, tehát véleményem szerint ez legfeljebb figyelmeztetés lehet.

Ha a gyorsítótár-bejegyzést nem lehetne törölni az engedélyekkel kapcsolatos problémák vagy valami harmadik dolog miatt, az kritikus hiba lenne, mert előfordulhat, hogy az NGINX a lejárati idő után is tovább szolgálja a gyorsítótárban tárolt tartalmat, de úgy tűnik, hogy a tisztítási folyamat nem tesz különbséget.