Miklix

NGINX-välimuistin poistaminen tuo kriittisiä linkityksen poistamisvirheitä virhelokiin

Julkaistu: 15. helmikuuta 2025 klo 11.24.03 UTC

Tässä artikkelissa kerrotaan, kuinka voit poistaa kohteita NGINX:n välimuistista ilman, että lokitiedostot ovat täynnä virheilmoituksia. Vaikka se ei yleensä ole suositeltava lähestymistapa, se voi olla hyödyllinen joissakin reunatapauksissa.


Tämä sivu on käännetty koneellisesti englannista, jotta se olisi mahdollisimman monen ihmisen saatavilla. Valitettavasti konekääntäminen ei ole vielä täydellistä tekniikkaa, joten virheitä voi esiintyä. Voit halutessasi tarkastella alkuperäistä englanninkielistä versiota täällä:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Tämän viestin tiedot perustuvat FastCGI-välimuistiin NGINX 1.4.6:ssa, joka toimii Ubuntu Server 14.04 x64:ssä. Se voi tai ei välttämättä ole voimassa muille versioille.

(Päivitys 2025: Alkuperäisen viestin kirjoittamisen ja tämän hetken välisenä aikana paljon on muuttunut. Palvelimet ovat nopeampia ja halvempia, joten en itse asiassa suosittelisi tässä viestissä kuvattua lähestymistapaa, jossa yritän mikrohallita välimuistin vanhenemista vain säästääkseni muutaman ylimääräisen sukupolven dynaamista sisältöä. Jätän sisällön tähän myöhempää tarvetta varten ja jos joku todella tarvitsee sitä ING:stä, tämä INX ei vieläkään toimi jostain syystä. kuitenkin, mutta luulisin sen tekevän).

Siirrettyään useita sivustoja Apachesta NGINX:ään, olen ihastunut kovasti sen sisäänrakennetuista välimuistiominaisuuksista, jotka toimivat erittäin hyvin useimmissa olosuhteissa ilman paljon sekaantumistani.

Yhden sivuston kohdalla tarvitsin kuitenkin todella mahdollisuuden tyhjentää välimuisti (sekä kokonaan että yksittäisten merkintöjen poistaminen). NGINX:n ilmainen yhteisöversio tukee vain aikaperusteista välimuistin vanhenemista (eli voit asettaa sen tarkistamaan, onko jokin muuttunut tunnin, päivän jne. jälkeen). Mutta entä jos ei ole luotettavaa tapaa määrittää etukäteen, milloin tietty resurssi muuttuu? Minulla ei esimerkiksi ole aavistustakaan, meneekö tunti, päivä vai vuosi, ennen kuin tulen takaisin ja muokkaan jotain tässä viestissä – ja miksi vain välimuistiin jääminen tunnin ajan, jos päivän välimuisti olisi ollut hyvä?

Tässä tarvitaan kyky tyhjentää välimuisti manuaalisesti (tai pyytämällä verkkosovellus ilmoittamaan NGINX:lle, että jotain pitäisi tyhjentää). NGINX:n takana olevat ihmiset ovat selvästi tietoisia tämän tarpeesta, koska ominaisuutta tuetaan heidän tuotteensa maksullisessa versiossa – mutta vaikka heillä on varmasti oikeus määrittää lisenssinsä haluamallaan tavalla, hinta on minulle hieman jyrkkä, kun tämä toiminto on ainoa maksullinen ominaisuus, jota todella tarvitsen.

Onneksi voit vain poistaa tiedostoja välimuistihakemistosta itse, ja NGINX poimii tämän ja hakee uuden kopion taustajärjestelmästäsi ilman ongelmia. Jos kuitenkin teet tämän säätämättä asetuksia, näet todennäköisesti koko joukon tämänkaltaisia ​​viestejä virhelokissasi hetken kuluttua:

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

Näyttää siltä, ​​​​että nämä virheet tapahtuvat, kun NGINX itse yrittää poistaa välimuistin merkintöjä fastcgi_cache_path -direktiivin passiivisen parametrin määrittämän ajan kuluttua. Oletusarvo tälle on vain 10 minuuttia, mutta voit asettaa sen mihin tahansa arvoon. Jos asetat sen esimerkiksi 10 vuodeksi, on todennäköisesti epätodennäköistä, että et ole käynnistänyt palvelinta uudelleen tällä välin, joten muistissa oleva avainindeksi olisi tyhjennetty sillä välin. Jos teet tämän, sinun on varmistettava , että tyhjennät välimuistin itse, NGINX ei enää tee sitä puolestasi.

Minusta on todella outoa, että sitä pidetään kriittisenä virheenä, että välimuistin merkintää ei voida poistaa, koska sitä ei ole olemassa. Se, että sen vakavuusluokitus on niin korkea, tarkoittaa, että siitä on mahdotonta päästä eroon vain jättämällä huomioimatta tietyn kynnyksen alapuolella olevat lokimerkinnät. Heti kun taustasta haetaan uusi kopio, merkintä on taas olemassa, joten tämän pitäisi mielestäni olla korkeintaan varoitus.

Jos välimuistin merkintää ei voitu poistaa käyttöoikeusongelmien tai jonkin kolmannen takia, se olisi kriittinen virhe, koska se saattaa saada NGINX:n jatkamaan välimuistissa olevan sisällön tarjoamista kauan sen vanhenemisajan jälkeen, mutta puhdistusprosessi ei näytä tekevän tätä eroa.

Jaa BlueskyssäJaa FacebookissaJaa LinkedInissäJaa TumblrissaJaa X:ssäJaa LinkedInissäPin Pinterestissä

Mikkel Bang Christensen

Kirjoittajasta

Mikkel Bang Christensen
Mikkel on miklix.com-sivuston luoja ja omistaja. Hänellä on yli 20 vuoden kokemus ammattimaisena tietokoneohjelmoijana/ohjelmistokehittäjänä, ja tällä hetkellä hän työskentelee kokopäiväisesti suuressa eurooppalaisessa IT-yrityksessä. Kun hän ei ole bloggaamassa, hän käyttää vapaa-aikaansa monenlaisiin kiinnostuksen kohteisiin, harrastuksiin ja aktiviteetteihin, mikä saattaa jossain määrin heijastua tällä verkkosivustolla käsiteltävien aiheiden moninaisuuteen.