Бришењето на кешот на NGINX става критични грешки за прекинување на врската во дневникот на грешки
Објавено: 5 март 2025, во 19:55:07 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 ќе го земе ова и ќе донесе нова копија од вашиот заден дел без проблем. Меѓутоа, ако го направите ова без да ја измените вашата конфигурација, веројатно ќе видите цел куп пораки слични на оваа во дневникот за грешки по некое време:
Се чини дека овие грешки се појавуваат кога самиот NGINX се обидува да ги избрише записите во кешот по времето одредено со неактивен параметар на директивата fastcgi_cache_path . Стандардно за ова е само 10 минути, но можете да го поставите на која било вредност што сакате. Ако го поставите на, да речеме, 10 години, веројатно е малку веројатно дека во меѓувреме не сте го рестартирале серверот, така што индексот на клучот во меморијата би бил исчистен во меѓувреме. Ако го направите ова, дали треба да се погрижите сами да го исчистите кешот, NGINX веќе нема да го прави тоа наместо вас.
Сметам дека е навистина чудно што се смета за критична грешка што записот од кешот не може да се избрише бидејќи не постои. Фактот дека нејзината класификација на сериозност е толку висока значи дека е невозможно да се ослободите од само со игнорирање на записите во дневникот под одреден праг. Штом се земе нова копија од задниот дел, записот повторно ќе постои, така што ова треба да биде најмногу предупредување, според мене.
Сега, ако записот во кешот не може да се избрише поради проблеми со дозволите или нешто трето, тоа би било критична грешка, бидејќи може да го натера NGINX да продолжи да служи кеширана содржина долго по неговото истекување, но се чини дека процесот на чистење не ја прави оваа разлика.