NGINX кэшийг устгаснаар алдааны бүртгэлд чухал салгах алдаа гардаг

Нийтэлсэн: 2025 оны гуравдугаар сарын 19 21:28:01 (UTC)

Энэ нийтлэлд NGINX-ийн кэшээс лог файлуудыг алдааны мессежээр дүүргэхгүйгээр хэрхэн устгах талаар тайлбарласан болно. Ерөнхийдөө санал болгож буй арга биш ч зарим захын тохиолдолд энэ нь ашигтай байж болох юм.

Энэ хуудсыг аль болох олон хүнд хүртээмжтэй болгох үүднээс англи хэлнээс орчуулсан. Харамсалтай нь машин орчуулга нь төгс төгөлдөр технологи болоогүй байгаа тул алдаа гарч болзошгүй. Хэрэв та хүсвэл англи хэл дээрх эх хувилбарыг эндээс үзэх боломжтой.

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Энэхүү нийтлэлд оруулсан мэдээлэл нь Ubuntu Server 14.04 x64 дээр ажилладаг NGINX 1.4.6 дээр FastCGI кэшлэлтэд суурилсан юм. Энэ нь бусад хувилбаруудад зөв байж болох ч, байж болохгүй.

(2025 оны шинэчлэл: Би анх нийтлэлээ бичихээс хойш олон зүйл өөрчлөгдсөн. Серверүүд илүү хурдан, хямд болсон тул би энэ нийтлэлд тайлбарласан, кэшийн хугацааг жижигхэн хугацаанд тохируулж динамик агуулгыг хэдэн үеийнхээр нь хадгалахын тулд оролддог аргачлалыг санал болгож чадахгүй байна. Би энэ агуулгыг ирээдүйн лавлагаа болон ямар нэгэн шалтгаанаар хэрэгтэй байгаа хүмүүст үлдээнэ. Тийм ч учраас одоогийн NGINX хувилбаруудад энэ ажиллах эсэхийг би баталгаажуулаагүй ч, магадгүй ажиллах байх гэж бодож байна.)

Apache-аас NGINX руу хэд хэдэн сайтыг шилжүүлснээр би түүний суурилуулсан кэшлэлийн чадварт үнэхээр дуртай болсон. Энэ нь ихэнх тохиолдолд ямар ч оролдлого хийхгүйгээр маш сайн ажилладаг.

Гэхдээ нэг сайтын хувьд, би кэшийг (бүхэлд нь болон тус бүрийн оруулгаыг устгах) өөрөө устгах боломжтой байх хэрэгтэй байсан. NGINX-ийн үнэгүй нийтийн хувилбар зөвхөн цаг хугацаа дээр суурилсан кэшийн хугацаа дуусахыг дэмждэг (жишээ нь, нэг цаг, нэг өдөр гэх мэт хугацаа өнгөрснөөс хойш өөрчлөгдсөн эсэхийг шалгах боломжтой). Гэхдээ хэрэв ямар нэгэн эх үүсвэрийн өөрчлөлт хэзээ болохыг урьдчилан тодорхойлох боломжгүй бол юу хийх вэ? Жишээ нь, би энэ нийтлэлд юу нэг хоног, нэг сар эсвэл жил дахин засварлах гэж ирэхийг мэдэхгүй. Тэгэхээр яагаад нэг цагийн турш кэшлэх ёстой гэж? Хэрэв нэг өдөр нь тохиромжтой бол?

Иймд кэшийг гар аргаар устгах (эсвэл таны вэб програм NGINX-д ямар нэгэн зүйлийг устгах хэрэгтэй гэдгийг мэдэгдэх) чадвар шаардлагатай байна. NGINX-ийн ард байгаа хүмүүс энэ хэрэгцээг ойлгож байгаа нь тодорхой, учир нь энэ боломж нь тэдний бүтээгдэхүүний төлбөртэй хувилбарт дэмжигддэг – гэхдээ тэд лицензийн үнийг хүссэнээрээ тохируулж болох ч, энэ үйл ажиллагаа нь ганцхан төлбөртэй функц бөгөөд үүнийг би үнэхээр хэрэгтэй гэж үзэж байгаа юм.

Аз болоход, та кэшийн хавтаснаас файлуудыг устгаж болох бөгөөд NGINX үүнийг анзаарч, таны арын серверээс шинэ хуудсыг амархан татаж авах болно. Гэхдээ хэрэв та энэ тохиргоог өөрчлөлтгүйгээр хийвэл, тодорхой хугацааны дараа таны алдаа логдонд ийм төрлийн олон мессеж гарч ирэх магадлалтай:

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 өөрөө inactive параметртэй fastcgi_cache_path тушаалаар заасан хугацаа дууссаны дараа кэшийн оруулгуудыг устгахыг оролддог үед гардаг бололтой. Үүний хувьд анхдагч хугацаа нь зөвхөн 10 минут байдаг ч, та хүссэн хугацаагаа тохируулах боломжтой. Жишээ нь, 10 жилийн хугацаатай бол та серверээ дахин эхлүүлэхгүй байх магадлалтай тул санах оруулгын индекс нь үүнийг хийсний дараа арилсан байх болно. Хэрэв та ингэвэл, та кэшийг өөрөө устгахыг тайвшруулж хийж байх хэрэгтэй, NGINX үүнийг дахиж хийхгүй байх болно.

Кэшийн оруулгыг устгаж чадахгүй байгааг шударга алдаа гэж үзэж байгааг би үнэхээр сонин гэж бодож байна. Энэ нь маш өндөр ноцтой байдалтай гэж ангилагдсан нь, тодорхой нэгэн түвшнээс доошх алдаа мэдэгдлүүдийг үл тоомсорлож устгах боломжгүй болгож байгаа юм. Хэрэв арын серверээс шинэ хуудсыг татаж авбал оруулга дахин оршин тогтнох болно, тиймээс үүнийг зөвхөн анхааруулга гэж үзэх ёстой гэж би бодож байна.

Харин, кэшийн оруулгыг устгаж чадаагүй шалтгаан нь зөвшөөрөлтэй холбоотой асуудал эсвэл өөр ямар нэгэн зүйл байсан бол, тэр нь үнэхээр ноцтой алдаа байх байсан, учир нь энэ нь NGINX-д кэшийн агуулгыг хугацаа дууссаны дараа удаан хугацаагаар үйлчилж байх боломжийг олгох магадлалтай бөгөөд цэвэрлэх процесс нь энэ ялгааг мэдэрдэггүй шиг байна.