Usunięcie pamięci podręcznej NGINX powoduje umieszczenie krytycznych błędów odłączania w dzienniku błędów

Informacje zawarte w tym poście opierają się na buforowaniu FastCGI w NGINX 1.4.6 działającym na Ubuntu Server 14.04 x64. Mogą być lub nie być ważne w przypadku innych wersji.

(Aktualizacja 2025: W czasie między napisaniem oryginalnego posta a teraz wiele się zmieniło. Serwery są szybsze i tańsze, więc w rzeczywistości nie polecałbym podejścia opisanego w tym poście, w którym próbuję mikrozarządzać wygasaniem pamięci podręcznej, aby zaoszczędzić kilka dodatkowych generacji dynamicznej zawartości. Pozostawię tę zawartość tutaj na przyszłość i na wypadek, gdyby ktoś faktycznie jej potrzebował z jakiegokolwiek powodu. Nie potwierdziłem jednak, że nadal działa to w przypadku obecnych wersji NGINX, ale myślę, że tak).

Po migracji kilku stron z Apache na NGINX bardzo spodobały mi się wbudowane funkcje buforowania, które w większości przypadków działają znakomicie bez mojej ingerencji.

Jednak w przypadku jednej ze stron naprawdę potrzebowałem możliwości samodzielnego czyszczenia pamięci podręcznej (zarówno całkowitego, jak i usuwania pojedynczych wpisów). Darmowa edycja społecznościowa NGINX obsługuje tylko wygasanie pamięci podręcznej oparte na czasie (tj. można ją skonfigurować tak, aby sprawdzała, czy coś się zmieniło po godzinie, dniu itd.). Ale co, jeśli nie ma niezawodnego sposobu na ustalenie z wyprzedzeniem, kiedy określony zasób ulegnie zmianie? Na przykład nie mam pojęcia, czy minie godzina, dzień czy rok, zanim wrócę i coś zmodyfikuję w tym poście – i dlaczego buforować tylko przez godzinę, skoro buforowanie przez dzień byłoby w porządku?

Tutaj potrzebna jest możliwość ręcznego czyszczenia pamięci podręcznej (lub poprzez powiadomienie aplikacji internetowej NGINX, że coś powinno zostać usunięte). Ludzie stojący za NGINX są wyraźnie świadomi potrzeby tego, ponieważ funkcja ta jest obsługiwana w płatnej wersji ich produktu – ale chociaż z pewnością mają prawo skonfigurować licencję w dowolny sposób, cena jest dla mnie trochę wysoka, gdy ta funkcja jest jedyną płatną funkcją, której naprawdę potrzebuję.

Na szczęście okazuje się, że możesz po prostu usunąć pliki z katalogu pamięci podręcznej samodzielnie, a NGINX to wykryje i pobierze nową kopię z Twojego zaplecza bez żadnych problemów. Jeśli jednak zrobisz to bez modyfikowania konfiguracji, prawdopodobnie po pewnym czasie zobaczysz w dzienniku błędów całą masę komunikatów podobnych do tego:

Wygląda na to, że te błędy występują, gdy NGINX próbuje usunąć wpisy pamięci podręcznej po czasie określonym przez parametr inactive dyrektywy fastcgi_cache_path . Domyślna wartość to tylko 10 minut, ale możesz ustawić ją na dowolną wartość. Jeśli ustawisz ją na przykład na 10 lat, prawdopodobnie mało prawdopodobne jest, że nie uruchomiłeś ponownie serwera w międzyczasie, więc indeks klucza w pamięci zostałby wyczyszczony w międzyczasie. Jeśli to zrobisz, czy musisz upewnić się, że sam wyczyścisz pamięć podręczną, NGINX nie będzie już tego robić za Ciebie.

Uważam za naprawdę dziwne, że uważa się za błąd krytyczny , że wpisu w pamięci podręcznej nie można usunąć, ponieważ nie istnieje. Fakt, że jego klasyfikacja ważności jest tak wysoka, oznacza, że nie można się go pozbyć, po prostu ignorując wpisy w dzienniku poniżej pewnego progu. Gdy tylko nowa kopia zostanie pobrana z zaplecza, wpis znów będzie istniał, więc moim zdaniem powinno to być co najwyżej ostrzeżenie.

Jeśli jednak nie udałoby się usunąć wpisu z pamięci podręcznej z powodu problemów z uprawnieniami lub czegoś trzeciego, byłby to błąd krytyczny, ponieważ mógłby spowodować, że NGINX nadal udostępniałby zawartość pamięci podręcznej długo po upływie jej terminu ważności, ale proces czyszczenia najwyraźniej nie bierze pod uwagę tego rozróżnienia.