Ištrynus NGINX talpyklą, klaidų žurnale atsiranda kritinių atsiejimo klaidų
Paskelbta: 2025 m. vasario 15 d. 11:24:17 UTC
Šiame straipsnyje paaiškinama, kaip ištrinti elementus iš NGINX talpyklos, kad žurnalo failai nebūtų perkrauti klaidų pranešimais. Nors paprastai tai nėra rekomenduojamas metodas, jis gali būti naudingas kai kuriais kraštutiniais atvejais.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Šiame įraše pateikta informacija yra pagrįsta FastCGI talpyklos kaupimu NGINX 1.4.6, veikiančio Ubuntu Server 14.04 x64. Jis gali galioti arba negalioja kitoms versijoms.
(2025 m. atnaujinimas: nuo to laiko, kai parašiau pradinį įrašą, ir dabar, daug kas pasikeitė. Serveriai yra greitesni ir pigesni, todėl iš tikrųjų nerekomenduočiau šiame įraše aprašyto būdo, kai bandau mikroreguliuoti talpyklos galiojimo laiką, kad sutaupyčiau keletą papildomų kartų dinamiško turinio. Turinį paliksiu čia, kad būtų galima pasinaudoti ateičiai, o jei kam nors iš tikrųjų jo prireiktų, šios INX versijos vis dar nepatvirtintų dėl kokių nors priežasčių. nors, bet aš manau, kad taip).
Perkėlus kelias svetaines iš „Apache“ į NGINX, labai pamėgau jo integruotas talpyklos talpinimo galimybes, kurios daugeliu atvejų veikia itin gerai, man nesikišant.
Tačiau vienoje iš svetainių man tikrai reikėjo galimybės pačiam išvalyti talpyklą (ir visiškai, ir pašalinti atskirus įrašus). Nemokamas bendruomenės NGINX leidimas palaiko tik laiku pagrįstą talpyklos galiojimo laiką (ty galite ją nustatyti, kad patikrintumėte, ar kas nors nepasikeitė po valandos, dienos ir pan.). Bet ką daryti, jei nėra patikimo būdo iš anksto nustatyti, kada pasikeis tam tikri ištekliai? Pavyzdžiui, neįsivaizduoju, ar praeis valanda, diena ar metai, kol grįšiu ir ką nors redaguosiu šiame įraše – ir kodėl tik valandėlę talpykloje saugoti, jei būtų buvę gerai laikyti talpyklą vieną dieną?
Čia reikia galimybės išvalyti talpyklą rankiniu būdu (arba žiniatinklio programai pranešus NGINX, kad kažkas turi būti išvalyta). Žmonės, dirbantys su NGINX, aiškiai supranta, kad tai reikalinga, nes ši funkcija palaikoma mokamoje jų produkto versijoje, tačiau nors jie tikrai turi teisę nustatyti savo licenciją bet kokiu būdu, kaina man yra šiek tiek didelė, kai ši funkcija yra vienintelė mokama funkcija, kurios man tikrai reikia.
Laimei, paaiškėja, kad galite tiesiog patys ištrinti failus iš talpyklos katalogo, o NGINX tai paims ir be kliūčių atsiųs naują kopiją iš jūsų fono. Tačiau jei tai padarysite nepakeitę konfigūracijos, greičiausiai po kurio laiko klaidų žurnale pamatysite daugybę pranešimų, panašių į šį:
Panašu, kad šios klaidos atsiranda, kai pati NGINX bando ištrinti talpyklos įrašus po laiko, nurodyto neaktyviame fastcgi_cache_path direktyvos parametre. Numatytoji reikšmė yra tik 10 minučių, bet galite nustatyti bet kokią norimą reikšmę. Jei nustatysite, tarkime, 10 metų, tikriausiai mažai tikėtina, kad tuo tarpu nepaleidote serverio iš naujo, kad tuo tarpu būtų išvalytas pagrindinis atminties indeksas. Jei tai padarysite, ar turite įsitikinti , kad patys išvalėte talpyklą, NGINX daugiau to nepadarys už jus.
Man labai keista, kad tai, kad talpyklos įrašo negalima ištrinti, nes jo nėra, laikoma kritine klaida. Faktas, kad jo sunkumo klasifikacija yra tokia aukšta, reiškia, kad jo neįmanoma atsikratyti vien ignoruojant žurnalo įrašus, esančius žemiau tam tikros ribos. Kai tik nauja kopija bus gauta iš galinės dalies, įrašas vėl egzistuos, todėl, mano nuomone, tai turėtų būti daugiausia įspėjimas.
Dabar, jei talpyklos įrašo nepavyko ištrinti dėl problemų, susijusių su leidimais ar ko nors trečia, tai būtų kritinė klaida, nes dėl to NGINX gali tęsti talpyklos turinio aptarnavimą dar ilgai pasibaigus jo galiojimo laikui, tačiau neatrodo, kad valymo procesas to išskirtų.