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

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ć?

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

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.

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

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ć.

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;
}

Uznałem to za przydatne

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

Wyszukaj, a jeśli znaleziono, usuń.

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.

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" me@gmail.com
exit 0

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!

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;
    }
}

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ą”.

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.

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ę.

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).

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.

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

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.

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;

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ąć.

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

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

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).