NGINX Cache-ի ջնջումը կրիտիկական unlink սխալները տեղադրում է սխալ log-ում

Հրապարակվել է՝ 15 փետրվարի, 2025 թ., 11:26:56 UTC

Այս հոդվածը բացատրում է, թե ինչպես կարելի է ջնջել NGINX-ի պահոցից եղած իրերը՝ առանց ձեր մատյանի ֆայլերը սխալ հաղորդագրություններով կեղտոտելու։ Թեեւ ընդհանուր առմամբ խորհուրդ չի տրվում կիրառել, սակայն որոշ եզրային դեպքերում այն կարող է օգտակար լինել։

Այս էջը ավտոմատ կերպով թարգմանվել է անգլերենից՝ հնարավորինս շատ մարդկանց համար հասանելի դարձնելու համար: Ցավոք, մեքենայական թարգմանությունը դեռ կատարելագործված տեխնոլոգիա չէ, ուստի կարող են սխալներ առաջանալ: Եթե նախընտրում եք, կարող եք դիտել բնօրինակ անգլերեն տարբերակը այստեղ.

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Այս պոստում տեղադրված տեղեկատվությունը հիմնված է FastCGI caching on NGINX 1.4.6 running on Ubuntu Server 14.04 x64. Այն կարող է կամ չի կարող վավերական լինել այլ տարբերակների համար։

(Update 2025: Իմ միջեւ ընկած ժամանակահատվածում ես գրեցի բնօրինակը եւ հիմա շատ բան է փոխվել: Սերվերները ավելի արագ են եւ էժան, ուստի ես իրականում խորհուրդ չեմ տա այս փոստում նկարագրված մոտեցումը, որտեղ ես փորձում եմ միկրո-կառավարել cache expiry պարզապես մի քանի լրացուցիչ սերունդ դինամիկ բովանդակություն փրկելու համար: Ես կթողնեմ բովանդակությունը այստեղ ապագա հղումների համար, եւ եթե ինչ-որ մեկը իրականում դրա կարիքն ունենա ինչ-որ պատճառով: Ես չեմ հաստատել, որ սա դեռ աշխատում է NGINX-ի ներկայիս տարբերակների համար, բայց ես կարծում եմ, որ դա այդպես է):

Ապաչիից NGINX մի քանի կայքեր տեղափոխվելուց հետո ես շատ եմ սիրել նրա ներկառուցված պահեստավորման ունակությունները, որոնք շատ հանգամանքներում չափազանց լավ են աշխատում՝ առանց ինձնից շատ խառնվելու։

Սակայն կայքերից մեկի համար ես իսկապես կարիք ունեի ինքս մաքրելու պահոցը (եւ՛ ամբողջությամբ, եւ՛ հեռացնելու առանձին գրառումները)։ NGINX-ի անվճար համայնքային թողարկումը միայն աջակցում է ժամանակի վրա հիմնված cache expiry (այսինքն դուք կարող եք տեղադրել այն ստուգելու համար, թե արդյոք ինչ-որ բան փոխվել է մեկ ժամից հետո, մեկ օր եւ այլն): Իսկ ի ՞ նչ կարող ես անել, եթե նախօրոք որոշում չկա, թե կոնկրետ որ ռեսուրսը կփոխվի ։ Օրինակ, ես պատկերացում չունեմ, թե արդյոք կլինի ժամ, մեկ օր կամ մեկ տարի առաջ, երբ ես կվերադառնամ եւ ինչ-որ բան կխմբագրությամբ այս պոստում – եւ ինչո՞ւ միայն մեկ ժամ պահեք, եթե մեկ օր պահելը լավ կլիներ:

Ահա թե որտեղ է անհրաժեշտ ձեռքով մաքրել cache-ը (կամ ունենալով ձեր վեբ հավելվածը տեղեկացնել NGINX-ին, որ ինչ-որ բան պետք է մաքրվի): NGINX-ի հետեւում կանգնած մարդիկ հստակ գիտակցում են դրա անհրաժեշտությունը, քանի որ առանձնահատկությունը աջակցվում է իրենց արտադրանքի վճարովի տարբերակում – բայց թեեւ նրանք, անշուշտ, իրավունք ունեն իրենց լիցենզիան տեղադրել ցանկացած ձեւով, գինը մի քիչ խիստ է ինձ համար, երբ այս ֆունկցիան միակ վճարված առանձնահատկությունն է, որի կարիքը ես իսկապես ունեմ:

Բարեբախտաբար, պարզվում է, որ դուք կարող եք պարզապես ջնջել ֆայլերը cache-ի թղթապանակից ինքներդ եւ NGINX-ը կվերցնի սա եւ ձեր back-end-ից նոր պատճեն կբացեք առանց hitch-ի: Սակայն, եթե դուք դա անում եք առանց tweaking ձեր configuration, դուք, ամենայն հավանականությամբ, կտեսնեք մի ամբողջ խումբ հաղորդագրություններ, որոնք նման են այս մեկին ձեր սխալ մատյանում որոշ ժամանակ անց.

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-ն ինքը փորձում է ջնջել cache մուտքերը fastcgi_cache_path հրահանգի ոչ ակտիվ պարամետրով նշված ժամանակից հետո: Դրա համար նախապատվությունը տրվում է ընդամենը 10 րոպե, բայց դուք կարող եք այն դնել ցանկացած արժեքի վրա։ Եթե դուք սահմանել այն, ասենք, 10 տարի, հավանաբար քիչ հավանական է, որ դուք չեք վերսկսել սերվերը այդ ընթացքում, այնպես որ հիշողության մեջ բանալին այդ ընթացքում կմաքրվեր: Եթե դուք դա անում եք, արդյո՞ք պետք է համոզվեք, որ դուք մաքրում եք պահոցը ինքներդ, NGINX-ն այլեւս չի անի դա ձեզ համար:

Ես իսկապես տարօրինակ եմ համարում, որ համարվում է քննադատական սխալ, որ cache մուտքը չի կարող ջնջվել, քանի որ այն գոյություն չունի: Այն փաստը, որ դրա խստության դասակարգումն այնքան բարձր է, նշանակում է, որ անհնար է ձերբազատվել պարզապես որոշակի շեմից ներքեւ գտնվող գերանների գրառումները անտեսելով: Հենց որ նոր պատճենը բերվի հետնամասից, մուտքը կրկին գոյություն կունենա, ուստի սա պետք է նախազգուշացում լինի, իմ կարծիքով:

Այժմ, եթե cache մուտքը չէր կարող ջնջվել թույլտվությունների կամ ինչ-որ երրորդ բանի հետ կապված խնդիրների պատճառով, դա կլինի լուրջ սխալ, քանի որ այն կարող է ստիպել NGINX-ին իր ժամկետը լրանալուց երկար ժամանակ անց շարունակել սպասարկել պահված բովանդակությունը, բայց մաքրման գործընթացը կարծես թե չի տարբերում այս տարբերությունը: