Jak wyczyścić pamięć podręczną nginx?

250

Używam nginx jako serwera frontowego, zmodyfikowałem pliki CSS, ale nginx nadal obsługuje stare.

Próbowałem zrestartować nginx, ale bez skutku i przejrzałem Google, ale nie znalazłem prawidłowego sposobu na jego usunięcie.

Niektóre artykuły mówią, że możemy po prostu usunąć katalog pamięci podręcznej:, var/cache/nginxale takiego katalogu nie ma na moim serwerze.

Co mam teraz zrobić?

Freewind
źródło
1
Przydałoby się więcej szczegółów na temat konfiguracji Nginx. Używasz proxy_cache?
Alexander Azarov
Nie, właśnie użyłem domyślnej konfiguracji i szukałem ciągu znaków cache, ale nie znalazłem go w plikach konfiguracyjnych
Freewind
5
Nginx domyślnie nie buforuje.
Alexander Azarov
30
Czy pracujesz w Virtualbox / Vargant VM? Jeśli tak, spróbuj wyłączyć plik send, ponieważ nie działają razem dobrze.
kolbyjack
5
czy jesteś pewien, że buforowanie jest po stronie Nginx? Czy zweryfikowałeś zachowanie za pomocą narzędzia takiego jak zwijanie? Często takim problemem jest po prostu buforowanie po stronie klienta, które nie żąda zaktualizowanego zasobu, ponieważ powiedziano, że stary zasób będzie ważny przez długi czas do momentu wygaśnięcia max; lub coś podobnego.
kolbyjack,

Odpowiedzi:

185

Miałem dokładnie ten sam problem - działałem z moim nginx w Virtualbox. Nie miałem włączonego buforowania. Ale wygląda jak sendfilezostał ustawiony onw nginx.confi który był przyczyną problemu. @kolbyjack wspomniał o tym powyżej w komentarzach.

Kiedy się wyłączyłem sendfile- działało dobrze.

To dlatego, że:

Sendfile służy do „kopiowania danych między jednym deskryptorem pliku a innym” i najwyraźniej ma pewne poważne problemy, gdy jest uruchamiany w środowisku maszyny wirtualnej lub przynajmniej przez Virtualbox. Wyłączenie tej konfiguracji w nginx powoduje, że plik statyczny jest obsługiwany inną metodą, a twoje zmiany zostaną odzwierciedlone natychmiast i bez pytania

Jest to związane z tym błędem: https://www.virtualbox.org/ticket/12597

Deepan Chakravarthy
źródło
7
Zobacz ten link
Sian Lerk Lau,
W moim przypadku alternatywnym obejściem jest włączenie gzip dla tych typów plików. Tak czy inaczej problem zostanie rozwiązany.
Dingle
Dziękuję i kolbyjack bardzo za odpowiedź. Uratowałem mi życie.
T1000
1
Użyłem następującego „sudo vim /etc/nginx/nginx.conf” i zmieniłem „sendfile on” na „sendfile off”
Koray Güclü
12
Wyłączyłem sendfile. Brak szczęścia.
marukobotto
110

Możesz także ominąć / ponownie buforować plik po pliku za pomocą

proxy_cache_bypass $http_secret_header;

i jako bonus możesz zwrócić ten nagłówek, aby zobaczyć, czy dostałeś go z pamięci podręcznej (zwróci „HIT”) lub z serwera treści (zwróci „BYPASS”).

add_header X-Cache-Status $upstream_cache_status;

aby wygasnąć / odświeżyć buforowany plik, użyj curl lub innego klienta, aby wysłać żądanie do buforowanej strony.

curl http://abcdomain.com/mypage.html -s -I -H "secret-header:true"

zwróci to świeżą kopię elementu, a także zastąpi zawartość pamięci podręcznej.

Jason Wiener
źródło
7
Dlaczego mogę głosować tylko raz? Chcę zrobić gazillion :)
Spock
2
Może to aktualizować buforowane strony tylko wtedy, gdy nowa strona jest również buforowana. Jeśli usunąłeś stronę (404 lub inne błędy są teraz obsługiwane przez backend), strona wysyła teraz Set-Cookie lub nagłówek „Content-Control: private”, zawartość w pamięci podręcznej nie zostanie „unieważniona”.
rbu
3
Ten „add_header X-Cache-Status $ upstream_cache_status;” to taka fajna funkcja!
Maxim Masiutin
1
wielkie dzięki. fajna wskazówka na temat unieważnienia pamięci podręcznej, jest tak niewiele samouczków na temat nginx
Ivan Semochkin
4
Czy zmieniło się to od czasu opublikowania? Mogę z powodzeniem uzyskać nową kopię z „tajnym nagłówkiem”, ale jak tylko
usunę
60

O ile nie skonfigurowałeś strefy pamięci podręcznej za pomocą ścieżki proxy_cache_path, a następnie jej nie użyłeś (na przykład w bloku lokalizacji), za pośrednictwem: proxy_cache nic nie zostanie zapisane w pamięci podręcznej.

Jeśli tak, to według autora nginx wystarczy po prostu usunąć wszystkie pliki z katalogu pamięci podręcznej.

Najprostszy sposób: find /path/to/your/cache -type f -delete

Gnarfoz
źródło
Otrzymuję to w moim dzienniku błędów po usunięciu plików:[crit] 1640#0: unlink() "/path/to/cache/85/1cc5328db278b328f2c200c65179ad85" failed (2: No such file or directory)
Collin Anderson
Wielokrotnie czy tylko raz? To nie powinien być prawdziwy problem. Prawdopodobnie oznacza to po prostu, że menedżer pamięci podręcznej próbował usunąć plik, który już usunąłeś. Być może ponowne załadowanie nginx (przeładowanie nginx -s) może pomóc, jeśli otrzymujesz ten komunikat wielokrotnie. (Nie jestem pewien, czy to również ponownie
inicjuje
1
tak, automatycznie czyszczę pamięć podręczną mojej witryny za pomocą skryptu za każdym razem, gdy wdrażam zmianę, a przeładowanie nginx też tego nie naprawia.
Collin Anderson
Nop Nginx buforuje coś, nawet jeśli nie używasz proxy, ale jest to błąd w Nginx + VirtualBox.
Thomas Decaux,
1
To brzmi raczej niejasno. Czy mógłbyś to rozwinąć? Nie wydaje się, żeby miało to związek z omawianym tematem.
Gnarfoz
20

Możesz usunąć katalog pamięci podręcznej nginx lub przeszukać określony plik:

grep -lr 'http://mydomain.pl/css/myedited.css' /var/nginx/cache/*

I usuń tylko jeden plik, aby je odświeżyć.

Łukasz Sokolik
źródło
1
Aby uzyskać dokładne trafienie, możesz dodać $ do wyszukiwanego hasła. Jakgrep -lr 'http://mydomain.pl/css/myedited.css$' /var/nginx/cache/*
Jifeng Zhang
1
Niestety otrzymałem następujące dane wyjściowe: grep: /var/nginx/cache/*: No such file or directoryUżywam Ubuntu 14.04.3 LTS i nginx / 1.8.1. Dowolny pomysł?
b00r00x0
Spróbuj wykonać następujące czynności, aby grepować pliki w katalogu / var / nginx / cache:sudo find /var/nginx/cache -type f -exec grep -l '/css/myedited.css' {} \;
jaybrau
Sądzę, że to / var / cache / nginx / * (dir cache przed nginx na ścieżce)
Randy Lam
15

W tym pytaniu są dwie odpowiedzi.

  • Jeden dla nginx jako odwrotnej pamięci podręcznej
  • Kolejny do czyszczenia pamięci podręcznej przeglądarki przez wejście nagłówka (ten)

Posługiwać się:

expires modified +90d;

NA PRZYKŁAD:

location ~* ^.+\.(css|js|jpg|gif|png|txt|ico|swf|xml)$ {
    access_log off;
    root /path/to/htdocs;
    expires modified +90d;
}
deyes
źródło
Wypróbowałem tę implementację, ponieważ mam podobny problem. Jednak po dokonaniu zmiany - pokazuje domyślną stronę Nginx. Używam Niginx jako LB z proxy, czy może muszę zmienić root?
Aaron,
10

Uznałem to za przydatne

grep -lr 'jquery.js' /path/to/nginx/cache/folder/* | xargs rm

Wyszukaj, a jeśli znaleziono, usuń.

agustik
źródło
9

W mojej instalacji nginx stwierdziłem, że muszę iść do:

/opt/nginx/cache

i

sudo rm -rf *

w tym katalogu. Jeśli znasz ścieżkę do instalacji Nginx i możesz znaleźć katalog pamięci podręcznej, to samo może działać. Bądź bardzo ostrożny z rm -rfpoleceniem, jeśli jesteś w niewłaściwym katalogu, możesz usunąć cały dysk twardy.

Ganesh Shankar
źródło
2
po tym musisz zrestartować NGINX
Eliel Haouzi
I to jest zła część
kidz
9

Uruchamiam bardzo prosty skrypt bash, który zajmuje całe 10 sekund i wysyła mi pocztę po zakończeniu.

#!/bin/bash
sudo service nginx stop
sudo rm -rf /var/cache/nginx/*
sudo service nginx start | mail -s "Nginx Purged" [email protected]
exit 0
MitchellK
źródło
8

Też miałem ten problem.

  • Nie można znaleźć żadnego folderu nginx / cache
  • plik wysyłania był wyłączony

Moja domena korzysta z cloudflare.com dla DNS (świetna usługa!). Aha! To było:

cloudflare.com -> caching -> Purge Cache (wszystko wyczyściłem) To rozwiązało mój problem!

Asle
źródło
2
Czyści to pamięć podręczną Cloudflare. Nie usuwa pamięci podręcznej Nginx na twoim serwerze.
mahemoff
Myślę, że to dobra rada.
Fernando Kosh,
To była doskonała odpowiedź. Kopałem godziny, dlaczego niektóre pliki są nadal buforowane i nie mogłem odgadnąć, że to „wina” CloudFlare. Dzięki!
niezdefiniowany
6

Mamy bardzo dużą pamięć podręczną Nginx (gigabajty), którą czasami musimy wyczyścić. Opracowałem skrypt, który natychmiast czyści pamięć podręczną (jeśli chodzi o Nginx), a następnie usuwa katalog pamięci podręcznej bez głodzenia głównej aplikacji dyskowej we / wy.

W podsumowaniu:

  1. Przenieś folder pamięci podręcznej do nowej lokalizacji (w tym samym systemie plików!) (Nie zakłóci to żadnych otwartych deskryptorów plików)
  2. Utwórz ponownie oryginalny folder pamięci podręcznej, pusty
  3. Przeładuj Nginx ( płynne przeładowanie, w którym nginx pozwala starym pracownikom na ukończenie żądań w toku)
  4. Usuń stare dane z pamięci podręcznej

Oto skrypt, dostosowany do Ubuntu 16.04 LTS, z pamięcią podręczną /mnt/nginx-cache:

#!/bin/bash
set -e

TMPCACHE=`mktemp --directory --tmpdir=/mnt nginx-cache-XXXXXXXXXX`
TMPTEMP=`mktemp --directory --tmpdir=/mnt nginx-temp-XXXXXXXXXX`

# Move the old cache folders out of the way
mv /mnt/nginx-cache $TMPCACHE
mkdir -p /mnt/nginx-cache
chmod -R 775 /mnt/nginx-cache
chown www-data:www-data /mnt/nginx-cache

mv /mnt/nginx-temp $TMPTEMP
mkdir -p /mnt/nginx-temp
chmod -R 775 /mnt/nginx-temp
chown www-data:www-data /mnt/nginx-temp

# Tell Nginx about the new folders.
service nginx reload

# Create an empty folder.
rm -rf /mnt/empty
mkdir -p /mnt/empty

# Remove the old cache and old temp folders w/o thrashing the disk...
# See http://serverfault.com/questions/546177/how-to-keep-subtree-removal-rm-rf-from-starving-other-processes-for-disk-i
# Note: the `ionice` and `nice` may not actually do much, but why not?
ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ $TMPCACHE
ionice -c 3 nice -19 rsync -a --delete /mnt/empty/ $TMPTEMP
rm -rf $TMPCACHE
rm -rf $TMPTEMP

rm -rf /mnt/empty

A jeśli jest to pomocne, oto konfiguracja Nginx, której używamy:

upstream myapp {
    server localhost:1337 fail_timeout=0;
}

proxy_cache_path /mnt/nginx-cache/app levels=2:2:2 keys_zone=app_cache:100m inactive=1y max_size=10g;
proxy_temp_path  /mnt/nginx-temp/app;

server {
    listen   4316 default;
    server_name  myapp.com;

    location / {
        proxy_pass http://appserv;
        proxy_cache app_cache;
        proxy_cache_valid 200 1y;
        proxy_cache_valid 404 1m;
    }
}
David Eyk
źródło
5

Dla tych, którzy nie działają inne rozwiązania, sprawdź, czy korzystasz z usługi DNS, takiej jak CloudFlare . W takim przypadku aktywuj „Tryb programowania” lub użyj narzędzia „Wyczyść pamięć podręczną”.

Leopoldo Sanczyk
źródło
5

Pamiętaj, że proxy_cache_bypass może sprawić ci ból, jeśli twoja aplikacja nie zwróci buforowanej odpowiedzi dla tego konkretnego żądania, w którym je uruchomisz.

Jeśli na przykład aplikacja wysyła plik cookie przy każdym pierwszym żądaniu, skrypt, który wyzwala proxy_pass_bypass przez curl, prawdopodobnie otrzyma ten plik cookie w odpowiedzi, a nginx nie użyje tej odpowiedzi do odświeżenia pamięci podręcznej.

dwt
źródło
3
find /etc/nginx/cache_folder -type d -exec rm -rvf {} \;
mkdir /etc/nginx/cache_folder
service nginx restart

Uważaj, aby poprawnie określić poprawną ścieżkę.

colapsnux
źródło
3

Dla tych, którzy próbowali usunąć pliki pamięci podręcznej nginx i albo to nie działało, albo działało sporadycznie, spójrz na swoje ustawienie dla open_file_cache. Jeśli ta funkcja jest włączona i skonfigurowana do buforowania deskryptora pliku przez długi czas, Nginx może nadal widzieć wersję buforowanego pliku, nawet po usunięciu go z dysku. Musiałem zredukować wartość open_file_cache_valid do 1s (nie jestem pewien, czy jest to w zasadzie to samo, co całkowite wyłączenie bufora plików).

SilentMiles
źródło
2

Na moim serwerze znajduje się folder pamięci podręcznej nginx /data/nginx/cache/

Więc usunąłem tylko: sudo rm -rf /data/nginx/cache/

Mam nadzieję, że to pomoże każdemu.

Brilliant-DucN
źródło
2

Jeśli chcesz wyczyścić pamięć podręczną określonych plików, możesz skorzystać z proxy_cache_bypassdyrektywy. Tak to się robi

location / {
    proxy_cache_bypass $cookie_nocache $arg_nocache;
    # ...
}

Teraz, jeśli chcesz ominąć pamięć podręczną, uzyskasz dostęp do pliku, przekazując parametr nocache

http://www.example.com/app.css?nocache=true

Sajjad Ashraf
źródło
1
Sądzę, że można to wykorzystać do zaatakowania i zużycia przepustowości w Twojej witrynie.
Marcelo Agimóvel
1
Czy to nie pomija pamięci podręcznej dla bieżącego żądania ( app.css?nocache=true), podczas gdy oryginalny plik (bez zapytania) pozostaje w pamięci podręcznej ( app.css)?
adrianTNT
1

Możesz dodać konfigurację w nginx.conf w następujący sposób.

...
http {
proxy_cache_path  /tmp/nginx_cache levels=1:2 keys_zone=my-test-cache:8m max_size=5000m inactive=300m;

server {
    proxy_set_header X- Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_cache my-test-cache;
    proxy_cache_valid  200 302  1m;
    proxy_cache_valid  404      60m;
    proxy_cache_use_stale   error timeout invalid_header updating;
    proxy_redirect off;

    ....
}
...
}

Z góry folder o nazwie „nginx_cache” jest dynamicznie tworzony w / tmp / do przechowywania treści w pamięci podręcznej.

austinzmchen
źródło
1

Istnieje jedna właściwa metoda usuwania tylko plików pamięci podręcznej, która pasuje do dowolnego KLUCZA. Na przykład:

grep -lr 'KEY: yahoo' /var/lib/nginx/cache | xargs rm -rf

Spowoduje to usunięcie wszystkich plików pamięci podręcznej, które pasują do KLUCZA „yahoo / *”, jeśli ustawiono w pliku nginx.conf:

proxy_cache_key $host$uri;
Ivan BlaBlaBla
źródło
1

Używamy nginx do buforowania wielu rzeczy. W katalogu pamięci podręcznej znajdują się dziesiątki tysięcy elementów. Aby znaleźć elementy i je usunąć, opracowaliśmy kilka skryptów upraszczających ten proces. Repozytorium tych skryptów znajduje się poniżej:

https://github.com/zafergurel/nginx-cache-cleaner

Pomysł jest prosty. Aby utworzyć indeks pamięci podręcznej (z kluczami pamięci podręcznej i odpowiednimi plikami pamięci podręcznej) i wyszukać w tym pliku indeksu. Naprawdę pomogło nam to przyspieszyć znajdowanie przedmiotów (od minut do sekundy) i odpowiednio je usunąć.

Zafer
źródło
1

W moim przypadku touchten plik Css sprawia, że ​​wygląda na to, że zasoby zostały zmienione (w rzeczywistości touchnic nie robi z plikiem, oprócz zmiany czasu ostatniej modyfikacji), więc przeglądarka i nginx zastosują najnowsze zasoby

Noah
źródło
0

Wystąpił podobny problem:

Konfiguracja systemu i problem: (na wirtualnym pudełku hostuję za pomocą ubuntu i nginx - odświeżanie strony PHP nie odzwierciedla zmian w zewnętrznym pliku css). Zajmuję się tworzeniem witryny na komputerze z systemem Windows i przesyłaniem plików do nginx za pośrednictwem folderu udostępnionego. Wygląda na to, że nginx nie odbiera zmian w pliku css (odświeżanie w jakikolwiek sposób nie pomaga. Zmiana nazwy pliku css jest jedyną rzeczą, która działała)

Rozwiązanie: na maszynie wirtualnej znajdź udostępniony plik (w moim przypadku plik css). Otwórz za pomocą nano i porównaj z plikiem w udziale systemu Windows (wydają się identyczne). Na maszynie wirtualnej zapisz udostępniony plik w nano. Wszystkie zmiany są teraz odzwierciedlone w przeglądarce. Nie jestem pewien, dlaczego to działa, ale tak było w moim przypadku.

AKTUALIZACJA: Po ponownym uruchomieniu serwera VM problem powrócił. Postępowanie zgodnie z instrukcjami w części Rozwiązanie sprawiło, że css ponownie zareagował na aktualizacje

Pan G.
źródło
-1

W moim przypadku była to włączona opcache w /etc/php/7.2/fpm/php.ini (Ubuntu):

opcache.enable=1

Ustawienie wartości 0 spowodowało, że serwer ładuje najnowszą wersję plików (php).

Tech Nomad
źródło