Regularne czyszczenie cache na serwerze to jeden z najprostszych sposobów, by utrzymać przewidywalną wydajność aplikacji i uniknąć problemów z brakiem miejsca na dysku. Cache potrafi znacząco przyspieszyć działanie stron WWW i usług, ale gdy rośnie bez kontroli, zaczyna działać przeciwko nam: zwiększa zużycie storage, utrudnia diagnozowanie problemów po wdrożeniach i może powodować serwowanie nieaktualnych treści. Mechanizm CRON pozwala automatyzować takie porządki z precyzją co do minuty, a przy odpowiedniej konfiguracji czyszczenie cache jest bezpieczne, mierzalne i nie wpływa negatywnie na ruch.

Dlaczego cache się rozrasta i kiedy warto go czyścić automatycznie

Cache występuje niemal wszędzie: w warstwie HTTP (np. reverse proxy), w aplikacji (framework), w silniku PHP, w bazie danych, w systemie plików i w zewnętrznych usługach (Redis/Memcached). Część cache ma charakter krótkotrwały i sama się wygasza (TTL), ale w praktyce spotyka się wiele wyjątków: błędnie ustawione czasy życia, cache budowany „na stałe”, nadmiar danych tymczasowych po deployach czy po prostu brak mechanizmu usuwania starych wpisów.

Automatyczne czyszczenie cache przez CRON ma sens szczególnie wtedy, gdy:

• na hostingu współdzielonym nie masz stałego monitoringu, a lubisz „ustawić i zapomnieć”;
• aplikacja generuje pliki tymczasowe (miniatury, paczki, eksporty) i nie usuwa ich sama;
• masz ograniczoną przestrzeń dyskową lub restrykcyjne limity inode;
• po aktualizacjach zdarzają się problemy z nieaktualnymi zasobami (CSS/JS), a ręczne czyszczenie bywa pomijane;
• utrzymujesz kilka środowisk (staging/produkcja) i chcesz ujednolicić procedury.

Warto pamiętać, że cache nie jest wrogiem. Zbyt agresywne czyszczenie może przynieść efekt odwrotny: wzrost obciążenia CPU i I/O po „zimnym starcie”, wolniejsze generowanie stron oraz skoki w czasie odpowiedzi. Dlatego lepszą praktyką jest mądre usuwanie tylko tego, co przeterminowane albo bezpieczne do odtworzenia, oraz planowanie zadań poza godzinami szczytu.

Najczęstsze rodzaje cache na serwerach i hostingach

• Cache aplikacyjny (np. katalogi cache w frameworkach, pliki tymczasowe, dane sesyjne).
• Cache PHP (OPcache – zwykle nie czyści się go „na siłę” bez powodu, raczej resetuje przy deployu).
• Cache reverse proxy (np. Nginx/Varnish – często operuje na TTL i purge).
• Cache obiektowy (Redis/Memcached – wygaszanie kluczy, okresowe czyszczenie, polityki eviction).
• Cache CDN (Cloudflare i podobne – czyszczenie przez API lub reguły).
• Cache systemowy (np. pakiety, logi, tmp – tu zachowaj ostrożność i trzymaj się katalogów aplikacji).

Podstawy CRON: składnia, środowisko uruchomieniowe i dobre praktyki

CRON to harmonogram zadań w systemach Unix/Linux. Pozwala wykonać komendę w określonym czasie lub cyklicznie. Kluczowe jest zrozumienie, że zadania uruchamiane przez cron działają w „ubogim” środowisku: nie przejmują w pełni tego, co masz w sesji SSH (inne PATH, brak aliasów, brak interakcji). Stąd wiele problemów z „działa w konsoli, nie działa z crona”.

Składnia CRON i przykłady harmonogramów

Standardowy wpis crontab ma postać: minuta, godzina, dzień miesiąca, miesiąc, dzień tygodnia, a potem polecenie.

• Codziennie o 03:15: 15 3 * * *
• Co 10 minut: */10 * * * *
• W każdą niedzielę o 02:30: 30 2 * * 0
• W dni robocze o 01:00: 0 1 * * 1-5

W praktyce do czyszczenia cache często wybiera się godziny nocne lub okresy niskiego ruchu, a częstotliwość dopasowuje do tempa narastania danych. Lepiej zacząć ostrożnie (np. raz dziennie) i potem skracać interwał, niż od razu czyścić co 5 minut.

Crontab użytkownika vs systemowy

Najczęstsze podejścia:

• crontab użytkownika (np. crontab -e) – typowe na VPS i serwerach, gdy zadanie ma działać w kontekście Twojego konta.
• zadaniasystemowe w /etc/crontab lub katalogach /etc/cron.d/ – częściej w administracji serwerem, gdzie określasz też użytkownika uruchomieniowego.
• panel hostingowy – wiele hostingów pozwala dodawać cron z GUI, ale nadal warto znać składnię i zasady logowania.

Najważniejsze zasady bezpieczeństwa i przewidywalności

• Używaj pełnych ścieżek, np. /usr/bin/php, /usr/bin/find zamiast liczyć na PATH.
• Stosuj blokadę przed równoległym uruchomieniem (np. flock), aby zadanie nie wystartowało drugi raz, gdy poprzednie jeszcze działa.
• Loguj wynik do pliku i rotuj logi, aby sam cron nie zaczął „produkować śmieci”.
• Testuj na sucho: najpierw wykonaj komendę ręcznie na serwerze, potem dodaj do crona.
• Unikaj kasowania „na ślepo” katalogów systemowych. Skup się na katalogach aplikacji i zdefiniowanych miejscach cache.

Konfiguracja CRON do czyszczenia cache: scenariusze dla popularnych środowisk

W tej części znajdziesz praktyczne schematy czyszczenia cache – od prostego usuwania starych plików po bezpieczne skrypty z logowaniem i blokadą. Najbardziej uniwersalna zasada brzmi: czyść tylko to, co możesz bezpiecznie odtworzyć, i preferuj usuwanie plików przeterminowanych zamiast opróżniania całego cache.

Czyszczenie cache plikowego (file cache) przy użyciu find

Jeśli cache to katalog z plikami (np. aplikacja zapisuje rendery, miniatury, wyniki obliczeń), świetnie sprawdza się find z parametrami czasu. Przykład usuwa pliki starsze niż 7 dni w katalogu cache:

/usr/bin/find /var/www/twoja-aplikacja/storage/cache -type f -mtime +7 -delete

Jeśli chcesz usuwać puste katalogi po skasowaniu plików:

/usr/bin/find /var/www/twoja-aplikacja/storage/cache -type d -empty -delete

Wpis do crona (codziennie o 03:20) z logowaniem:

20 3 * * * /usr/bin/find /var/www/twoja-aplikacja/storage/cache -type f -mtime +7 -delete >> /var/log/cache-cleanup.log 2>&1

Uwaga: jeśli hosting nie pozwala pisać do /var/log, kieruj logi do katalogu w obrębie konta, np. ~/logs.

Bezpieczny skrypt bash: blokada, logi, kontrola rozmiaru

Lepszym wzorcem niż długa komenda w cronie jest skrypt, który łatwiej wersjonować i testować. Przykładowy skrypt cache_cleanup.sh:

#!/bin/bash
set -euo pipefail

LOCK=”/tmp/cache_cleanup.lock”
LOG=”/var/log/cache-cleanup.log”
CACHE_DIR=”/var/www/twoja-aplikacja/storage/cache”
DAYS=”7″

/usr/bin/flock -n „$LOCK” bash -c ’
echo „$(date -Is) start cleanup” >> „'”$LOG”'”
/usr/bin/find „'”$CACHE_DIR”'” -type f -mtime +'”$DAYS”’ -print -delete >> „'”$LOG”'” 2>&1
/usr/bin/find „'”$CACHE_DIR”'” -type d -empty -delete >> „'”$LOG”'” 2>&1
echo „$(date -Is) end cleanup” >> „'”$LOG”'”
’

Podłącz go w cronie:

20 3 * * * /bin/bash /var/www/twoja-aplikacja/scripts/cache_cleanup.sh

Warto też dodać kontrolę rozmiaru cache i warunkowe czyszczenie, np. gdy katalog przekroczy określony próg. Wtedy nie czyścisz „z rozpędu”, a reagujesz na realny problem.

WordPress: cache wtyczek, object cache i katalog uploads

Na hostingach WordPressowych spotkasz cache wtyczek (np. generowane pliki HTML), cache obiektowy oraz różne dane tymczasowe. Najbezpieczniej jest korzystać z mechanizmów przewidzianych przez aplikację albo wtyczkę, zamiast usuwać losowe katalogi.

Przykład: jeśli używasz WP-CLI, możesz czyścić transients i cache obiektowy (o ile jest skonfigurowany):

/usr/local/bin/wp transient delete –expired –path=/var/www/wordpress

Wpis do crona raz dziennie:

10 4 * * * /usr/local/bin/wp transient delete –expired –path=/var/www/wordpress >> /var/www/wordpress/wp-content/logs/wp-cron-cache.log 2>&1

Jeśli stosujesz rozwiązania typu Redis as Object Cache, czyszczenie „wszystkiego” (flushall) jest ryzykowne, bo wyczyści cache także innych aplikacji współdzielących Redis. W takim wypadku lepsza jest praca na prefiksach kluczy lub kontrola TTL.

Laravel/Symfony i frameworkowe komendy cache

Frameworki zwykle oferują komendy do czyszczenia cache i podmiany cache po deployu. Przykładowo w Laravelu możesz wykonać:

• /usr/bin/php /var/www/app/artisan cache:clear
• /usr/bin/php /var/www/app/artisan config:clear
• /usr/bin/php /var/www/app/artisan route:clear
• /usr/bin/php /var/www/app/artisan view:clear

W Symfony typowe są:

• /usr/bin/php /var/www/app/bin/console cache:clear
• /usr/bin/php /var/www/app/bin/console cache:pool:clear

Takie komendy świetnie nadają się do uruchamiania po wdrożeniu (CI/CD), ale bywają też wykonywane cyklicznie, jeśli masz niestandardowe cache lub chcesz wymuszać porządek w plikach cache na hostingu bez „hooków” deployowych. Pamiętaj jednak, że pełne czyszczenie cache frameworka w godzinach ruchu może spowodować chwilowe spowolnienie.

Nginx/Varnish: purge zamiast kasowania plików

Jeżeli cache jest na poziomie reverse proxy, lepiej stosować mechanizm purge (usuwanie konkretnych obiektów) niż opróżniać cały magazyn. W Varnish typową praktyką jest ban/purge po URL lub nagłówkach. W Nginx cache bywa plikowy, ale usuwanie „w ciemno” potrafi powodować niepotrzebny load. Rozważ polityki TTL i odpowiednie nagłówki Cache-Control, a czyszczenie zostaw jako „plan awaryjny”.

Redis/Memcached: wygaszanie, polityki eviction i ostrożne czyszczenie

W Redisie na serwerach hostingowych szczególnie ważne jest, czy Redis jest współdzielony. Komendy typu FLUSHALL mogą wyczyścić dane wielu aplikacji. Bezpieczniejsze podejście to:

• ustawianie TTL na kluczach;
• rozsądna konfiguracja maxmemory i polityki usuwania (allkeys-lru, volatile-lru);
• czyszczenie tylko kluczy z danym prefiksem (skryptowo, z SCAN, nie KEYS).

Jeśli musisz usuwać klucze po prefiksie, rób to ostrożnie i porcjami, aby nie zabić wydajności. CRON może uruchamiać skrypt, który iteruje po SCAN i usuwa ograniczoną liczbę kluczy na cykl.

Monitoring, logowanie i unikanie typowych pułapek

Samo dodanie wpisu do crona to dopiero połowa sukcesu. Najczęstsze problemy w automatycznym czyszczeniu cache wynikają z braku widoczności: skrypt nie działa, nie ma uprawnień, usuwa za dużo albo uruchamia się w złym momencie. Dobrze zaprojektowany proces ma jasne logi i prostą możliwość wycofania zmian.

Jak sprawdzić, czy CRON działa i gdzie są logi

• Na wielu VPS-ach logi crona są w /var/log/syslog lub /var/log/cron (zależnie od dystrybucji).
• Na hostingach współdzielonych często nie masz dostępu do systemowych logów, więc kluczowe jest logowanie do pliku w katalogu użytkownika.
• Możesz dodać do komendy prosty „heartbeat”, np. dopisanie daty do logu przy starcie.

Uprawnienia, właściciel plików i ryzyko usunięcia nie tego, co trzeba

Cache często jest generowany przez innego użytkownika niż ten, z którego uruchamiasz cron (np. www-data vs konto SSH). To prowadzi do błędów Permission denied. Rozwiązania:

• ujednolić właściciela i grupę katalogów cache;
• ustawić poprawne prawa (z rozwagą, bez 777);
• uruchamiać cron w odpowiednim kontekście użytkownika (na serwerze z rootem).

Druga pułapka to zbyt szeroka ścieżka w find. Zanim użyjesz -delete, przetestuj listowanie plików parametrem -print i upewnij się, że filtr czasu działa zgodnie z oczekiwaniami. Przydaje się też ograniczenie do jednego systemu plików, np. opcją -xdev, jeśli istnieje ryzyko zejścia do podmontowanych zasobów.

Planowanie okien serwisowych i wpływ na wydajność

Czyszczenie cache może generować sporo operacji dyskowych. Jeśli katalog zawiera setki tysięcy plików, samo przeszukanie drzewka może obciążyć serwer. Wtedy rozważ:

• czyszczenie częściej, ale mniejszymi porcjami;
• zmianę struktury cache (mniej plików, dłuższe TTL, inny backend);
• użycie narzędzi aplikacyjnych (np. czyszczenie po kluczach) zamiast masowego skanowania katalogów;
• migrację części cache do Redis/Memory, jeśli pasuje do profilu aplikacji.

Strategie: pełne czyszczenie vs selektywne usuwanie

Pełne „wipe” cache bywa kuszące, bo jest proste, ale najczęściej nieoptymalne. Lepsze strategie to:

• usuwanie plików po czasie (mtime), czyli selektywnie;
• usuwanie po rozmiarze (gdy katalog przekroczy próg);
• czyszczenie po wdrożeniu (gdy zmieniają się assety i zależności);
• stosowanie wersjonowania cache (cache busting) zamiast kasowania.

Gdy podejdziesz do tematu w ten sposób, CRON staje się narzędziem utrzymania porządku, a nie „młotkiem” do rozwiązywania problemów z wydajnością.

Przykładowe gotowe wpisy CRON dla hostingu i VPS

Poniżej zestaw wzorców, które możesz dopasować do własnego środowiska. Każdy z nich warto najpierw uruchomić ręcznie i sprawdzić log.

1) Usuwanie plików cache starszych niż 3 dni (hosting współdzielony)

5 2 * * * /usr/bin/find /home/user/public_html/cache -type f -mtime +3 -delete >> /home/user/logs/cache.log 2>&1

2) Czyszczenie katalogu tmp aplikacji raz na dobę z blokadą

30 3 * * * /usr/bin/flock -n /tmp/app_tmp.lock /usr/bin/find /var/www/app/tmp -type f -mtime +2 -delete >> /var/log/app-tmp.log 2>&1

3) Porządkowanie miniatur starszych niż 30 dni (oszczędzanie inode)

0 4 * * 0 /usr/bin/find /var/www/app/public/thumbnails -type f -mtime +30 -delete >> /var/log/thumbs.log 2>&1

4) Usuwanie wygasłych transientów w WordPress (WP-CLI)

15 4 * * * /usr/local/bin/wp transient delete –expired –path=/var/www/wordpress >> /var/www/wordpress/wp-content/logs/transients.log 2>&1

5) Reset cache po deployu (wariant „ręczny” uruchamiany z crona o stałej porze)

0 1 * * * /usr/bin/php /var/www/app/artisan cache:clear >> /var/log/laravel-cache.log 2>&1

Ten ostatni przykład ma sens tylko wtedy, gdy wiesz, że aktualizacje wchodzą przed 01:00 lub gdy cache potrafi się „rozjechać” niezależnie od wdrożeń. W przeciwnym razie lepiej wiązać czyszczenie z pipeline wdrożeniowym.

Podsumowanie: jak dobrać harmonogram i nie stracić korzyści z cache

CRON jest prostym i niezawodnym mechanizmem automatyzacji, ale w kontekście cache najważniejsze są decyzje projektowe: automatyzacja ma utrzymywać porządek, a nie maskować problemy z konfiguracją TTL, narastaniem plików czy nieprzemyślaną strategią buforowania. Najlepiej sprawdza się podejście selektywne: usuwanie plików przeterminowanych, stosowanie blokad przed równoległym uruchomieniem, solidne logowanie i testy na sucho. Dzięki temu czyszczenie cache staje się przewidywalnym elementem utrzymania serwera, a nie ryzykowną operacją wykonywaną dopiero wtedy, gdy kończy się miejsce na dysku.