Mupus Cache NGINX Nempatkeun Kasalahan Unlink Kritis dina Log Kasalahan

Diterbitkeun: 15 Pébruari 2025 jam 11.27.47 UTC

Artikel ieu ngécéskeun kumaha carana mupus item tina cache NGINX tanpa ngabogaan file log anjeun cluttered kalawan pesen kasalahan. Sanaos henteu umumna pendekatan anu disarankeun, éta tiasa mangpaat dina sababaraha kasus tepi.

Kaca ieu ditarjamahkeun ku mesin tina basa Inggris supados tiasa diaksés ku saloba-lobana jalma. Hanjakalna, tarjamahan mesin henteu acan janten téknologi anu sampurna, janten kasalahan tiasa lumangsung. Upami anjeun hoyong, anjeun tiasa ningali versi Inggris asli di dieu:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Informasi dina pos ieu dumasar kana FastCGI cache on NGINX 1.4.6 ngajalankeun on Ubuntu Server 14.04 x64. Ieu bisa atawa bisa jadi teu valid pikeun vérsi séjén.

(Update 2025: Dina waktos antara kuring nyerat tulisan asli sareng ayeuna, seueur anu parantos robih. Server langkung gancang sareng langkung mirah, janten kuring saleresna henteu nyarankeun pendekatan anu dijelaskeun dina tulisan ieu dimana kuring nyobian ngokolakeun cache kadaluwarsa ngan ukur nyimpen sababaraha generasi tambahan tina eusi dinamis. Abdi pikir éta henteu).

Saatos migrasi sababaraha situs ti Apache ka NGINX, kuring resep pisan kana kamampuan caching anu diwangun, anu tiasa dianggo saé dina kalolobaan kaayaan tanpa seueur campur tangan ti kuring.

Nanging, pikeun salah sahiji situs, kuring peryogi pisan kamampuan pikeun mupus cache (duanana lengkep sareng ngahapus éntri individu) nyalira. Édisi komunitas bébas NGINX ngan ukur ngadukung kadaluwarsa cache dumasar-waktos (nyaéta anjeun tiasa nyetél pikeun mariksa naha aya anu robih saatos sajam, sadinten, jsb.). Tapi kumaha upami teu aya cara anu tiasa dipercaya pikeun nangtoskeun sateuacanna nalika sumber daya anu tangtu bakal robih? Salaku conto, kuring henteu terang upami éta bakal sajam, sadinten atanapi sataun sateuacan kuring uih deui sareng ngédit hiji hal dina tulisan ieu - sareng naha ngan ukur cache sajam upami cache sadinten bakal saé?

Ieu dimana kamampuan pikeun mupus cache sacara manual (atanapi ku aplikasi wéb anjeun ngabéjaan NGINX yén aya anu kedah dibersihkeun) diperyogikeun. Jalma-jalma di tukangeun NGINX jelas sadar kana kabutuhan ieu kusabab fitur ieu dirojong dina versi anu mayar produkna - tapi sanaos aranjeunna pasti ngagaduhan hak nyetél lisénsina ku cara naon waé anu dipikahoyong, hargana rada lungkawing pikeun kuring nalika fungsi ieu mangrupikeun hiji-hijina fitur anu mayar anu kuring peryogikeun.

Untungna, tétéla anjeun ngan ukur tiasa ngahapus file tina diréktori cache nyalira sareng NGINX bakal nyandak ieu sareng nyandak salinan énggal tina tonggong anjeun tanpa halangan. Nanging, upami anjeun ngalakukeun ieu tanpa ngarobih konfigurasi anjeun, anjeun kamungkinan ningali sakumpulan pesen anu sami sareng ieu dina log kasalahan anjeun saatos sababaraha waktos:

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

Nembongan yen kasalahan ieu lumangsung nalika NGINX sorangan nyoba mupus éntri cache sanggeus waktu dieusian ku parameter teu aktif tina diréktif fastcgi_cache_path . Standar pikeun ieu ngan ukur 10 menit, tapi anjeun tiasa nyetél kana nilai naon waé anu anjeun pikahoyong. Upami anjeun nyetél éta, sebutkeun, 10 taun, sigana sigana anjeun teu acan ngamimitian deui server samentawis janten indéks konci dina mémori bakal diberesihan samentawis. Upami anjeun ngalakukeun ieu, naha anjeun kedah mastikeun yén anjeun ngabersihan cache nyalira, NGINX moal deui ngalakukeun pikeun anjeun.

Kuring manggihan bener aneh nu dianggap kasalahan kritis nu entri cache teu bisa dihapus sabab teu aya. Kanyataan yén klasifikasi severity na kacida luhurna hartina teu mungkin pikeun ngaleungitkeun ngan ku malire éntri log handap ambang nu tangtu. Pas salinan anyar dicandak tina back-end éntri bakal aya deui, janten ieu kedah janten peringatan paling-paling, dina pamanggih kuring.

Ayeuna, upami éntri cache teu tiasa dipupus kusabab masalah idin atanapi anu katilu, éta bakal janten kasalahan kritis, sabab éta tiasa ngajantenkeun NGINX neraskeun ngaladénan eusi sindangan lami saatos waktos béakna, tapi prosés ngabersihan sigana henteu ngabédakeun ieu.