Miklix

Брисање НГИНКС кеш меморије ставља критичне грешке за отказивање везе у дневник грешака

Објављено: 15. фебруар 2025. 11:28:25 UTC

Овај чланак објашњава како да избришете ставке из НГИНКС-ове кеш меморије без да ваше датотеке евиденције буду претрпане порукама о грешци. Иако се генерално не препоручује приступ, може бити користан у неким ивичним случајевима.


Ова страница је машински преведена са енглеског како би била доступна што већем броју људи. Нажалост, машинско превођење још увек није усавршена технологија, тако да може доћи до грешака. Ако желите, можете погледати оригиналну енглеску верзију овде:

Deleting NGINX Cache Puts Critical Unlink Errors in Error Log

Информације у овом посту су засноване на ФастЦГИ кеширању на НГИНКС 1.4.6 који ради на Убунту Сервер 14.04 к64. Може, али и не мора бити важеће за друге верзије.

(Ажурирање 2025: У периоду од када сам написао оригиналну објаву до сада, много се променило. Сервери су бржи и јефтинији, тако да у ствари не бих препоручио приступ описан у овом посту где покушавам да микро-управљам истеком кеша само да бих сачувао неколико додатних генерација динамичког садржаја. Оставићу садржај овде за будућу референцу и у случају да неко заиста не потврди да ова верзија још увек ради. НГИНКС, међутим, али мислим да јесте).

Након миграције неколико локација са Апацхе-а на НГИНКС, веома сам заволео његове уграђене могућности кеширања, које раде изузетно добро у већини околности без мог пуног мешања.

Међутим, за једну од локација ми је заиста била потребна могућност да сам обришем кеш (и потпуно и уклоним појединачне уносе). Бесплатно друштвено издање НГИНКС-а подржава само временско истек кеша (тј. можете га подесити да провери да ли се нешто променило након једног сата, дана, итд.). Али шта ако не постоји поуздан начин да се унапред одреди када ће се одређени ресурс променити? На пример, немам појма да ли ће проћи сат, дан или година пре него што се вратим и уредим нешто у овом посту – и зашто би кеширао само сат времена ако би кеширање за један дан било у реду?

Овде је потребна могућност ручног брисања кеша (или тако што ће ваша веб апликација обавестити НГИНКС да нешто треба да се очисти). Људи који стоје иза НГИНКС-а јасно су свесни потребе за овим јер је ова функција подржана у плаћеној верзији њиховог производа – али иако они свакако имају право да подесе своје лиценцирање на било који начин желе, цена је мало превисока за мене када је ова функција једина плаћена функција која ми заиста треба.

На срећу, испоставило се да можете сами да избришете датотеке из кеш директоријума и НГИНКС ће то схватити и без проблема преузети нову копију са вашег позадинског дела. Међутим, ако ово урадите без подешавања своје конфигурације, вероватно ћете после неког времена видети гомилу порука сличних овој у евиденцији грешака:

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

Чини се да се ове грешке јављају када сам НГИНКС покуша да избрише уносе у кеш меморију након времена наведеног неактивним параметром директиве фастцги_цацхе_патх . Подразумевано за ово је само 10 минута, али можете да га подесите на било коју вредност коју желите. Ако га поставите на, рецимо, 10 година, вероватно је мало вероватно да нисте поново покренули сервер у међувремену, тако да би индекс кључа у меморији био обрисан у међувремену. Ако то урадите, да ли треба да будете сигурни да сами обришете кеш, НГИНКС то више неће радити уместо вас.

Сматрам да је заиста чудно што се сматра критичном грешком то што унос у кеш не може бити обрисан јер не постоји. Чињеница да је његова класификација озбиљности тако висока значи да је немогуће отарасити се само игнорисањем уноса у евиденцији испод одређеног прага. Чим се нова копија преузме са позадине, унос ће поново постојати, тако да би ово, по мом мишљењу, требало да буде највише упозорење.

Сада, ако се унос кеша не би могао избрисати због проблема са дозволама или нечег трећег, то би била критична грешка, јер би то могло довести до тога да НГИНКС настави да сервира кеширани садржај дуго након његовог истека, али изгледа да процес чишћења не прави ову разлику.

Поделите на БлуескиПоделите на ФејсбукуДелите на ЛинкедИнуПодели на Тумблр-уПодели на КсДелите на ЛинкедИнуПин на Пинтерест-у

Миккел Банг Кристенсен

О аутору

Миккел Банг Кристенсен
Миккел је креатор и власник миклик.цом. Има преко 20 година искуства као професионални компјутерски програмер/програмер софтвера и тренутно је запослен са пуним радним временом у великој европској ИТ корпорацији. Када не пише блог, своје слободно време проводи на широком спектру интересовања, хобија и активности, што се у извесној мери може одразити на разноврсност тема обрађених на овој веб страници.