Изтриването на кеша на NGINX поставя критични грешки при прекратяване на връзката в регистъра на грешките

Публикувано: 15 февруари 2025 г. в 11:23:24 ч. UTC

Тази статия обяснява как да изтривате елементи от кеша на NGINX, без регистрационните файлове да са претрупани със съобщения за грешки. Въпреки че обикновено не е препоръчителен подход, той може да бъде полезен в някои крайни случаи.

Тази страница е машинно преведена от английски език, за да бъде достъпна за възможно най-много хора. За съжаление машинният превод все още не е съвършена технология, така че могат да възникнат грешки. Ако предпочитате, можете да видите оригиналната версия на английски език тук:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Информацията в тази публикация се основава на кеширане на FastCGI на NGINX 1.4.6, работещ на Ubuntu Server 14.04 x64. Може да е валидно или да не е валидно за други версии.

(Актуализация 2025: Във времето между писането на оригиналната публикация и сега, много неща се промениха. Сървърите са по-бързи и по-евтини, така че всъщност не бих препоръчал подхода, описан в тази публикация, където се опитвам да управлявам изтичането на кеша само за да спестя няколко допълнителни поколения динамично съдържание. Ще оставя съдържанието тук за бъдещи справки и в случай, че някой наистина има нужда от него по някаква причина. Не съм потвърдил, че това все още работи за текущите версии на NGINX, но мисля, че работи).

След като мигрирах няколко сайта от Apache към NGINX, много се привързах към вградените му възможности за кеширане, които работят изключително добре при повечето обстоятелства без много намеса от моя страна.

За един от сайтовете обаче наистина имах нужда от възможността сам да изчистя кеша (както напълно, така и да премахна отделни записи). Безплатното издание на общността на NGINX поддържа само изтичане на кеша, базирано на времето (т.е. можете да го настроите да проверява дали нещо се е променило след час, ден и т.н.). Но какво ще стане, ако няма надежден начин да се определи предварително кога определен ресурс ще се промени? Например, нямам представа дали ще мине час, ден или година, преди да се върна и да редактирам нещо в тази публикация – и защо да кеширам само за един час, ако кеширането за един ден би било добре?

Това е мястото, където е необходима възможността за ръчно изчистване на кеша (или чрез уведомяване на вашето уеб приложение за NGINX, че нещо трябва да бъде изчистено). Хората зад NGINX ясно са наясно с необходимостта от това, тъй като функцията се поддържа в платената версия на техния продукт – но въпреки че със сигурност имат право да настроят лицензирането си по какъвто начин искат, цената е малко висока за мен, когато тази функция е единствената платена функция, от която наистина се нуждая.

За щастие се оказва, че можете просто сами да изтриете файлове от директорията на кеша и NGINX ще вземе това и ще извлече ново копие от вашия бекенд без проблеми. Въпреки това, ако направите това, без да променяте конфигурацията си, вероятно ще видите цял куп съобщения, подобни на това в регистъра на грешките си след известно време:

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

Изглежда, че тези грешки възникват, когато самият NGINX се опита да изтрие записи в кеша след времето, определено от неактивния параметър на директивата fastcgi_cache_path . По подразбиране за това е само 10 минути, но можете да го зададете на каквато стойност искате. Ако го зададете, да речем, на 10 години, вероятно е малко вероятно междувременно да не сте рестартирали сървъра, така че ключовият индекс в паметта да е бил изчистен междувременно. Ако направите това, трябва ли да се уверите , че сами сте изчистили кеша, NGINX вече няма да го прави вместо вас.

Намирам за наистина странно, че се счита за критична грешка, че запис в кеша не може да бъде изтрит, защото не съществува. Фактът, че класификацията му по тежест е толкова висока, означава, че е невъзможно да се отървете от него само чрез игнориране на записите в дневника под определен праг. Веднага щом бъде извлечено ново копие от задната част, записът ще съществува отново, така че това би трябвало да е най-много предупреждение, според мен.

Сега, ако записът в кеша не може да бъде изтрит поради проблеми с разрешенията или нещо трето, това би било критична грешка, защото може да накара NGINX да продължи да обслужва кеширано съдържание дълго след изтичането му, но процесът на почистване изглежда не прави тази разлика.