Odstranění mezipaměti NGINX umístí kritické chyby odpojení do protokolu chyb
Vydáno: 15. února 2025 v 11:23:31 UTC
Tento článek vysvětluje, jak odstranit položky z mezipaměti NGINX, aniž by byly soubory protokolu přeplněné chybovými zprávami. Ačkoli to není obecně doporučený přístup, může být užitečný v některých okrajových případech.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Informace v tomto příspěvku jsou založeny na ukládání do mezipaměti FastCGI na NGINX 1.4.6 běžícím na Ubuntu Server 14.04 x64. Může a nemusí platit pro jiné verze.
(Aktualizace 2025: V době mezi napsáním původního příspěvku a nyní se toho hodně změnilo. Servery jsou rychlejší a levnější, takže bych ve skutečnosti nedoporučoval přístup popsaný v tomto příspěvku, kdy se snažím mikrospravovat vypršení mezipaměti, jen abych ušetřil několik generací dynamického obsahu navíc. Obsah zde nechám pro budoucí použití a pro případ, že by ho někdo skutečně potřeboval z jakéhokoli důvodu, ale u aktuálních verzí to stále funguje, nemám potvrzeno. dělá).
Po migraci několika webů z Apache na NGINX jsem si velmi oblíbil jeho vestavěné možnosti ukládání do mezipaměti, které ve většině případů fungují velmi dobře, aniž bych se do toho nějak vměšoval.
U jednoho z webů jsem však opravdu potřeboval možnost vymazat mezipaměť (jak úplně, tak odstranit jednotlivé položky) sám. Bezplatná komunitní edice NGINX podporuje pouze vypršení platnosti mezipaměti na základě času (tj. můžete ji nastavit tak, aby zkontrolovala, zda se něco nezměnilo po hodině, dni atd.). Ale co když neexistuje spolehlivý způsob, jak předem určit, kdy se určitý zdroj změní? Například netuším, jestli to bude hodina, den nebo rok, než se vrátím a něco upravím v tomto příspěvku – a proč ukládat do mezipaměti pouze hodinu, když by ukládání do mezipaměti na den bylo v pořádku?
Zde je potřeba možnost vymazat mezipaměť ručně (nebo tím, že vaše webová aplikace upozorní NGINX, že by mělo být něco vyčištěno). Lidé za NGINX si jasně uvědomují, že je to potřeba, protože tato funkce je podporována v placené verzi jejich produktu – ale i když jsou jistě oprávněni nastavit své licencování jakkoli chtějí, cena je pro mě trochu strmá, když je tato funkce jedinou placenou funkcí, kterou opravdu potřebuji.
Naštěstí se ukázalo, že můžete smazat soubory z adresáře mezipaměti sami a NGINX se toho chopí a bez problémů načte novou kopii z vašeho back-endu. Pokud to však uděláte bez vyladění konfigurace, pravděpodobně po chvíli uvidíte v protokolu chyb celou řadu zpráv podobných této:
Zdá se, že k těmto chybám dochází, když se NGINX sám pokusí smazat záznamy mezipaměti po době určené neaktivním parametrem direktivy fastcgi_cache_path . Výchozí hodnota je pouze 10 minut, ale můžete ji nastavit na libovolnou hodnotu. Pokud jej nastavíte například na 10 let, je pravděpodobně nepravděpodobné, že jste mezitím server nerestartovali, takže index klíče v paměti by byl mezitím vymazán. Pokud to uděláte, musíte se ujistit , že vymažete mezipaměť sami, NGINX to již nebude dělat za vás.
Připadá mi opravdu zvláštní, že je považováno za kritickou chybu, že položku mezipaměti nelze smazat, protože neexistuje. Skutečnost, že její klasifikace závažnosti je tak vysoká, znamená, že se jí nelze zbavit pouhým ignorováním položek protokolu pod určitou prahovou hodnotou. Jakmile se z back-endu načte nová kopie, záznam bude znovu existovat, takže by to podle mého názoru mělo být maximálně varování.
Nyní, pokud by záznam mezipaměti nemohl být smazán kvůli problémům s oprávněními nebo něčemu třetímu, byla by to kritická chyba, protože by to mohlo způsobit, že NGINX bude pokračovat v poskytování obsahu uloženého v mezipaměti dlouho po uplynutí doby platnosti, ale nezdá se, že by proces čištění dělal tento rozdíl.