Fshirja e cache NGINX vendos gabime kritike unlink në logun e gabimeve

Publikuar: 15 shkurt 2025 në 11:25:39 e paradites, UTC

Ky artikull shpjegon se si të fshini artikujt nga cache-i i NGINX-it pa pasur skedarët tuaj log të ngjeshur me mesazhe gabimi. Edhe pse në përgjithësi nuk është një metodë e rekomanduar, ajo mund të jetë e dobishme në disa raste të skajshme.

Kjo faqe u përkthye me makinë nga anglishtja për ta bërë të aksesueshme për sa më shumë njerëz. Fatkeqësisht, përkthimi me makinë nuk është ende një teknologji e përsosur, kështu që mund të ndodhin gabime. Nëse preferoni, mund ta shikoni versionin origjinal në anglisht këtu:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Informacioni në këtë postim bazohet në fastCGI caching në NGINX 1.4.6 që funksionon në Ubuntu Server 14.04 x64. Mund të jetë ose jo e vlefshme për versione të tjera.

(Update 2025: Në kohën mes kam shkruar postimin origjinal dhe tani, shumë gjëra kanë ndryshuar. Serverat janë më të shpejtë dhe më të lirë, kështu që në fakt nuk do të rekomandoja qasjen e përshkruar në këtë postim ku përpiqem të mikro-menaxhoj skadimin e cache vetëm për të kursyer disa gjenerata shtesë të përmbajtjes dinamike. Unë do ta lë përmbajtjen këtu për referencën e ardhshme dhe në rast se dikush në fakt ka nevojë për të për çfarëdo arsye. Unë nuk kam konfirmuar se kjo ende punon për versionet aktuale të NGINX, megjithatë, por unë do të mendoj se ajo e bën).

Pas migrimit të disa siteve nga Apache në NGINX unë jam rritur shumë i dhënë pas aftësive të saj të ndërtuara në kaching, e cila punon jashtëzakonisht mirë në shumicën e rrethanave pa u përzier shumë nga unë.

Megjithatë, për një nga faqet, kisha vërtet nevojë për aftësinë për të pastruar cache-in (si plotësisht ashtu edhe për të hequr hyrjet individuale) vetë. Edicioni i lirë komunitar i NGINX mbështet vetëm skadimin e cache-it të bazuar në kohë (d.m.th. ju mund ta vendosni atë për të kontrolluar nëse diçka ka ndryshuar pas një ore, një dite, etj.). Po sikur të mos ketë një mënyrë të besueshme për të përcaktuar që më përpara se kur do të ndryshojë një burim i caktuar? Për shembull, nuk e kam idenë nëse do të jetë një orë, një ditë apo një vit para se të kthehem dhe të redaktoj diçka në këtë postim – dhe pse vetëm cache për një orë nëse kaching për një ditë do të kishte qenë mirë?

Këtu nevojitet aftësia për të pastruar cache-in manualisht (ose duke pasur aplikacionin tuaj web të njoftojë NGINX se diçka duhet të shlyhet). Njerëzit prapa NGINX janë qartësisht të vetëdijshëm për nevojën për këtë pasi veçoria mbështetet në versionin e paguar të produktit të tyre – por ndërsa ata sigurisht kanë të drejtë të vendosin licencimin e tyre në çdo mënyrë që duan, çmimi është pak i pjerrët për mua kur ky funksion është i vetmi tipar i paguar që më duhet vërtet.

Për fat të mirë, rezulton se ju thjesht mund të fshini skedarët nga directory cache vetë dhe NGINX do të marrë në këtë dhe do të marrë një kopje të re nga back-end tuaj pa një hitch. Megjithatë, nëse e bëni këtë pa ndryshuar konfigurimin tuaj ka të ngjarë të shihni një tufë të tërë mesazhesh të ngjashme me këtë në logun tuaj të gabimeve pas një kohe:

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

Duket se këto gabime ndodhin kur vetë NGINX përpiqet të fshijë hyrjet në cache pas kohës së specifikuar nga parametri joaktiv i direktivës fastcgi_cache_path . Prezgjedhuri për këtë është vetëm 10 minuta, por ju mund ta vendosni atë në çfarëdo vlere që dëshironi. Nëse e vendosni për, të themi, 10 vjet, ka shumë mundësi që nuk ka gjasa që të mos e keni rifilluar serverin ndërkohë kështu që indeksi kyç në memorie do të ishte pastruar ndërkohë. Nëse e bëni këtë, a duhet të siguroheni që ta pastroni vetë cache-in, NGINX nuk do ta bëjë më për ju.

Më duket vërtet e çuditshme që konsiderohet si një gabim kritik që një hyrje në cache nuk mund të hiqet sepse nuk ekziston. Fakti që klasifikimi i tij i ashpërsisë është kaq i lartë do të thotë se është e pamundur të heqësh qafe vetëm duke shpërfillur hyrjet e logut nën një prag të caktuar. Sapo një kopje e re të nxirret nga pjesa e pasme hyrja do të ekzistojë përsëri, kështu që ky duhet të jetë një paralajmërim më së shumti, për mendimin tim.

Tani, nëse hyrja në cache nuk do të mund të fshihej për shkak të problemeve me lejet apo diçka të tretë, ky do të ishte një gabim kritik, sepse mund të bëjë që NGINX të vazhdojë të shërbejë përmbajtje të cached shumë kohë pas kohës së skadimit të saj, por procesi i pastrimit nuk duket se e bën këtë dallim.