NGINX ქეშის წაშლა შეცდომის ჟურნალში კრიტიკულ Unlink შეცდომებს აყენებს
გამოქვეყნებულია: 15 თებერვალი, 2025, 11:27:44 UTC
ამ სტატიაში ახსნილია, თუ როგორ უნდა წაშალოთ ელემენტები NGINX– ის ქეშიდან, თქვენი ჟურნალის ფაილების შეცდომის შეტყობინებებით შეკვრის გარეშე. მიუხედავად იმისა, რომ ზოგადად არ არის რეკომენდებული მიდგომა, ეს შეიძლება სასარგებლო იყოს ზოგიერთ ზღვარზე.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
ამ პოსტში ინფორმაცია ეფუძნება FastCGI ქეშირს NGINX 1.4.6-ზე, რომელიც მუშაობს Ubuntu Server 14.04 x64-ზე. ეს შეიძლება იყოს ან არ იყოს მოქმედი სხვა ვერსიებისთვის.
(განახლება 2025: იმ დროს, როდესაც მე დავწერე ორიგინალური პოსტი და ახლა, ბევრი რამ შეიცვალა. სერვერები უფრო სწრაფი და იაფია, ამიტომ მე ნამდვილად არ გირჩევთ ამ პოსტში აღწერილ მიდგომას, სადაც ვცდილობ მიკრო მართვას ქეშის ვადა მხოლოდ დინამიური შინაარსის რამდენიმე დამატებითი თაობის შესანახად. მე აქ დავტოვებ შინაარსს მომავალი მითითებისთვის და იმ შემთხვევაში, თუ ვინმეს ეს რეალურად სჭირდება რაიმე მიზეზით. მე არ დავადასტურე, რომ ეს ჯერ კიდევ მუშაობს NGINX– ის მიმდინარე ვერსიებზე, მაგრამ მე ვფიქრობ, რომ ეს ასეა).
Apache– დან NGINX– ზე რამდენიმე საიტის მიგრაციის შემდეგ მე ძალიან მიყვარდა მისი ჩაშენებული ქეშირების შესაძლებლობები, რომლებიც უმეტეს შემთხვევაში ძალიან კარგად მუშაობს ჩემგან დიდი ჩარევის გარეშე.
ამასთან, ერთ-ერთი საიტისთვის, მე ნამდვილად მჭირდებოდა ქეშის გასუფთავების შესაძლებლობა (როგორც სრულად, ასევე ინდივიდუალური ჩანაწერების ამოღება). NGINX– ის უფასო საზოგადოების გამოცემა მხარს უჭერს მხოლოდ დროზე დაფუძნებულ ქეშის ვადას (ე.ი. შეგიძლიათ დააყენოთ ის, რომ შეამოწმოთ შეიცვალა თუ არა რამე ერთი საათის შემდეგ, დღეში და ა.შ.). მაგრამ რა მოხდება, თუ არ არსებობს საიმედო გზა წინასწარ განსაზღვრის დროს, როდესაც გარკვეული რესურსი შეიცვლება? მაგალითად, წარმოდგენა არ მაქვს, იქნება თუ არა ეს ერთი საათი, ერთი დღე თუ ერთი წლით ადრე, სანამ დავბრუნდები და ამ პოსტში რაღაცას შევცვლი - და რატომ მხოლოდ ქეში ერთი საათის განმავლობაში, თუ ერთი დღის ქეშირება კარგად იქნებოდა?
ეს არის ის, სადაც საჭიროა ქეშის ხელით გაწმენდის შესაძლებლობა (ან თქვენი ვებ აპლიკაციის საშუალებით აცნობოს NGINX- ს, რომ რაღაც უნდა იყოს გაწმენდილი). NGINX– ის უკან მყოფმა ადამიანებმა ნათლად იციან ამის საჭიროება, რადგან ფუნქცია მხარდაჭერილია მათი პროდუქტის ფასიან ვერსიაში - მაგრამ მიუხედავად იმისა, რომ მათ ნამდვილად აქვთ უფლება დააყენონ თავიანთი ლიცენზირება ნებისმიერი გზით, რაც მათ სურთ, ფასი ჩემთვის ცოტა ციცაბოა, როდესაც ეს ფუნქცია ერთადერთი ფასიანი ფუნქციაა, რაც ნამდვილად მჭირდება.
საბედნიეროდ, გამოდის, რომ თქვენ შეგიძლიათ უბრალოდ წაშალოთ ფაილები ქეშის დირექტორიიდან და NGINX აიღებს ამას და მიიღებს ახალ ასლს თქვენი უკანა ბოლოდან შეფერხების გარეშე. ამასთან, თუ ამას აკეთებთ თქვენი კონფიგურაციის შესწორების გარეშე, თქვენ სავარაუდოდ ნახავთ ამ მსგავსი შეტყობინებების მთელ თაიგულს თქვენს შეცდომის ჟურნალში გარკვეული პერიოდის შემდეგ:
როგორც ჩანს, ეს შეცდომები ხდება მაშინ, როდესაც NGINX თავად ცდილობს ქეშის ჩანაწერების წაშლას fastcgi_cache_path დირექტივის არააქტიური პარამეტრით მითითებული დროის შემდეგ. ამის ნაგულისხმევი მხოლოდ 10 წუთია, მაგრამ შეგიძლიათ დააყენოთ ის, რაც გსურთ. თუ თქვენ დააყენებთ მას, ვთქვათ, 10 წლის განმავლობაში, ალბათ ნაკლებად სავარაუდოა, რომ თქვენ არ გადატვირთეთ სერვერი იმავდროულად, ასე რომ მეხსიერების ძირითადი ინდექსი გასუფთავდებოდა იმავდროულად. თუ ამას გააკეთებთ, უნდა დარწმუნდეთ, რომ ქეში თავად გაასუფთავეთ, NGINX აღარ გააკეთებს ამას თქვენთვის.
მე ნამდვილად უცნაურად მიმაჩნია, რომ კრიტიკულ შეცდომად ითვლება, რომ ქეშის ჩანაწერი არ შეიძლება წაიშალოს, რადგან ის არ არსებობს. ის ფაქტი, რომ მისი სიმძიმის კლასიფიკაცია იმდენად მაღალია, ნიშნავს, რომ შეუძლებელია მოშორება მხოლოდ გარკვეული ბარიერის ქვემოთ ჟურნალის ჩანაწერების იგნორირებით. როგორც კი ახალი ასლი მიიღება უკანა ბოლოდან, ჩანაწერი კვლავ იარსებებს, ასე რომ, ეს უნდა იყოს გაფრთხილება ყველაზე მეტად, ჩემი აზრით.
ახლა, თუ ქეშის ჩანაწერი ვერ წაიშალა ნებართვებთან დაკავშირებული პრობლემების ან რაიმე მესამედის გამო, ეს იქნება კრიტიკული შეცდომა, რადგან ამან შეიძლება NGINX გააგრძელოს ქეშირებული შინაარსის მომსახურება მისი ვადის ამოწურვიდან დიდი ხნის შემდეგ, მაგრამ გაწმენდის პროცესი არ წარმოადგენს ამ განსხვავებას.