Mbusak Cache NGINX Nempatake Kesalahan Mbusak Tautan Kritis ing Log Kesalahan

Diterbitake: 15 Februari 2025 ing 11:25:36 UTC

Artikel iki nerangake carane mbusak item saka cache NGINX tanpa file log sampeyan kecemplung karo pesen kesalahan. Sanajan ora umum minangka pendekatan sing disaranake, bisa uga migunani ing sawetara kasus pinggiran.

Kaca iki diterjemahake mesin saka basa Inggris supaya bisa diakses dening akeh wong. Sayange, terjemahan mesin durung dadi teknologi sing sampurna, mula kesalahan bisa kedadeyan. Yen sampeyan seneng, sampeyan bisa ndeleng versi Inggris asli ing kene:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Informasi ing kirim iki adhedhasar FastCGI caching ing NGINX 1.4.6 mlaku ing Ubuntu Server 14.04 x64. Bisa uga ora bener kanggo versi liyane.

(Update 2025: Ing antarane aku nulis kiriman asli lan saiki, akeh sing wis diganti. Server luwih cepet lan luwih murah, mula aku ora bakal nyaranake pendekatan sing diterangake ing postingan iki, ing ngendi aku nyoba ngatur cache kadaluwarsa mung kanggo nyimpen sawetara generasi konten dinamis. Aku bakal mikir yen bisa).

Sawise migrasi sawetara situs saka Apache menyang NGINX, aku seneng banget karo kemampuan caching sing dibangun, sing bisa digunakake kanthi apik ing kahanan sing paling akeh tanpa campur tangan saka aku.

Nanging, kanggo salah sawijining situs, aku pancene butuh kemampuan kanggo mbusak cache (loro kanthi lengkap lan mbusak entri individu) dhewe. Edisi komunitas gratis NGINX mung ndhukung kadaluwarsa cache adhedhasar wektu (yaiku sampeyan bisa nyetel kanggo mriksa apa ana owah-owahan sawise jam, sedina, lsp). Nanging kepiye yen ora ana cara sing bisa dipercaya kanggo nemtokake manawa sumber daya tartamtu bakal diganti? Contone, aku ora ngerti yen bakal dadi jam, dina utawa taun sadurunge aku bali lan nyunting soko ing kirim iki - lan apa mung cache kanggo jam yen caching kanggo dina bakal wis nggoleki?

Iki ngendi kemampuan kanggo mbusak cache kanthi manual (utawa aplikasi web sampeyan ngabari NGINX yen ana sing kudu diresiki). Wong-wong sing ana ing mburi NGINX jelas ngerti babagan kabutuhan iki amarga fitur kasebut didhukung ing versi mbayar produke - nanging nalika dheweke mesthi duwe hak kanggo nyetel lisensi kanthi cara apa wae sing dikarepake, regane rada curam kanggo aku nalika fungsi iki mung siji-sijine fitur mbayar sing aku butuhake.

Untunge, ternyata sampeyan mung bisa mbusak file saka direktori cache dhewe lan NGINX bakal njupuk iki lan njupuk salinan anyar saka mburi tanpa alangan. Nanging, yen sampeyan nindakake iki tanpa ngapiki konfigurasi sampeyan, sampeyan bakal bisa ndeleng akeh pesen sing padha karo iki ing log kesalahan sawise sawetara wektu:

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

Katon yen kesalahan kasebut kedadeyan nalika NGINX dhewe nyoba mbusak entri cache sawise wektu sing ditemtokake dening parameter ora aktif saka arahan fastcgi_cache_path . Default kanggo iki mung 10 menit, nanging sampeyan bisa nyetel iku kanggo nilai apa wae sing pengin. Yen sampeyan nyetel kanggo, ngomong, 10 taun, iku mbokmenawa ora bisa miwiti maneh server ing sawetoro wektu supaya indeks tombol ing memori wis dibusak ing sauntara. Yen sampeyan nindakake iki, sampeyan kudu nggawe manawa sampeyan mbusak cache dhewe, NGINX ora bakal nindakake kanggo sampeyan.

Aku nemokake iku pancene aneh sing dianggep minangka kesalahan kritis sing entri cache ora bisa dibusak amarga ora ana. Kasunyatan bilih klasifikasi keruwetan kasebut dhuwur banget tegese ora bisa diilangi mung kanthi ora nggatekake entri log ing ngisor ambang tartamtu. Sanalika salinan anyar dijupuk saka mburi mburi entri bakal ana maneh, dadi iki kudu dadi bebaya paling, ing mratelakake panemume.

Saiki, yen entri cache ora bisa dibusak amarga ana masalah karo ijin utawa soko katelu, sing bakal dadi kesalahan kritis, amarga bisa nggawe NGINX terus nglayani konten sing di-cache suwene suwene wektu kadaluwarsa, nanging proses resik-resik katon ora mbedakake iki.