Dzēšot NGINX kešatmiņu, kļūdu žurnālā tiek parādītas kritiskas atsaistes kļūdas
Publicēts: 2025. gada 15. februāris 11:24:19 UTC
Šajā rakstā ir paskaidrots, kā izdzēst vienumus no NGINX kešatmiņas, nepārblīvējot žurnālfailus ar kļūdu ziņojumiem. Lai gan tā parasti nav ieteicama pieeja, tā var būt noderīga dažos gadījumos.
Deleting NGINX Cache Puts Critical Unlink Errors in Error Log
Šajā ziņā sniegtā informācija ir balstīta uz FastCGI kešatmiņu operētājsistēmā NGINX 1.4.6, kas darbojas uz Ubuntu Server 14.04 x64. Tas var būt un var nebūt derīgs citām versijām.
(2025. gada atjauninājums: laikā no sākotnējās ziņas rakstīšanas līdz tagadnei daudz kas ir mainījies. Serveri ir ātrāki un lētāki, tāpēc es neieteiktu šajā ziņā aprakstīto pieeju, kurā mēģinu mikropārvaldīt kešatmiņas derīguma termiņu, lai saglabātu dažas papildu dinamiskā satura paaudzes. Atstāšu saturu šeit turpmākai uzziņai, un gadījumā, ja kādam tas tiešām ir vajadzīgs, šī INX versija joprojām nedarbojas kāda iemesla dēļ. lai gan, bet es domāju, ka tā ir).
Pēc vairāku vietņu migrēšanas no Apache uz NGINX man ļoti iepatikās tās iebūvētās kešatmiņas iespējas, kas vairumā gadījumu darbojas ļoti labi, man neiejaucoties.
Tomēr vienai no vietnēm man patiešām bija nepieciešama iespēja pašam notīrīt kešatmiņu (gan pilnībā, gan noņemt atsevišķus ierakstus). NGINX bezmaksas kopienas izdevums atbalsta tikai uz laiku balstītu kešatmiņas derīguma termiņu (ti, varat to iestatīt, lai pārbaudītu, vai pēc stundas, dienas utt. kaut kas nav mainījies). Bet ko darīt, ja nav ticama veida, kā iepriekš noteikt, kad kāds resurss mainīsies? Piemēram, man nav ne jausmas, vai paies stunda, diena vai gads, līdz es atgriezīšos un kaut ko rediģēšu šajā ziņā — un kāpēc tikai stundu saglabāt kešatmiņu, ja kešatmiņas saglabāšana vienu dienu būtu bijusi piemērota?
Šeit ir nepieciešama iespēja manuāli notīrīt kešatmiņu (vai tīmekļa lietojumprogrammai paziņojot NGINX, ka kaut kas ir jāiztīra). Cilvēki, kas ir aiz NGINX, skaidri apzinās, ka tas ir nepieciešams, jo šī funkcija tiek atbalstīta viņu produkta maksas versijā, taču, lai gan viņiem noteikti ir tiesības iestatīt licenci jebkurā veidā, man cena ir nedaudz zema, ja šī funkcija ir vienīgā maksas funkcija, kas man patiešām ir nepieciešama.
Par laimi, izrādās, ka varat vienkārši pats izdzēst failus no kešatmiņas direktorija, un NGINX to uztvers un bez aizķeršanās ienesīs jaunu kopiju no jūsu aizmugures. Tomēr, ja to darāt, nemainot konfigurāciju, visticamāk, pēc kāda laika kļūdu žurnālā redzēsit veselu virkni ziņojumu, kas ir līdzīgi šim:
Šķiet, ka šīs kļūdas rodas, kad NGINX pats mēģina dzēst kešatmiņas ierakstus pēc laika, kas norādīts neaktīvajā direktīvas fastcgi_cache_path parametrā. Noklusējuma vērtība ir tikai 10 minūtes, taču varat iestatīt to uz jebkuru vēlamo vērtību. Ja iestatāt, teiksim, uz 10 gadiem, visticamāk, ka pa šo laiku neesat restartējis serveri, tāpēc atmiņas atslēgas indekss tikmēr būtu notīrīts. Ja jūs to darāt, vai jums ir jāpārliecinās , ka pats iztīrāt kešatmiņu, NGINX vairs to nedarīs jūsu vietā.
Man šķiet patiešām dīvaini, ka kešatmiņas ierakstu nevar izdzēst, jo tā neeksistē, tiek uzskatīta par kritisku kļūdu. Fakts, ka tā smaguma pakāpe ir tik augsta, nozīmē, ka no tā nav iespējams atbrīvoties, vienkārši ignorējot žurnāla ierakstus zem noteikta sliekšņa. Tiklīdz no aizmugures tiks iegūta jauna kopija, ieraksts atkal pastāvēs, tāpēc, manuprāt, tam vajadzētu būt brīdinājumam.
Tagad, ja kešatmiņas ierakstu nevar izdzēst atļauju problēmu vai kaut kā trešā dēļ, tā būtu kritiska kļūda, jo tas var likt NGINX turpināt apkalpot kešatmiņā saglabāto saturu vēl ilgi pēc tā derīguma termiņa beigām, taču šķiet, ka tīrīšanas procesā šī atšķirība nenotiek.