Automatyzacja zaczyna szkodzić wtedy, gdy wszystkie zadania próbują wejść na serwer jednocześnie. Raport o północy, backup o północy, synchronizacja o północy, wysyłka maili też o północy — a potem zdziwienie, że aplikacja odpowiada wolniej niż zwykle albo proces PHP wisi przez pół godziny. Cron nie jest problemem. Problemem jest traktowanie go jak silnika do ciężkiej pracy, zamiast jak prostego harmonogramu, który powinien tylko uruchamiać właściwe mechanizmy we właściwym czasie.
Cron powinien planować, a nie dźwigać całą pracę
Cron robi jedną rzecz: uruchamia polecenie zgodnie z harmonogramem. Nie wie, czy skrypt ma przetworzyć 50 rekordów czy 5 milionów. Nie pilnuje, czy poprzednie uruchomienie nadal trwa. Nie rozumie priorytetów. Dlatego zadania cykliczne trzeba projektować tak, jakby każde z nich mogło kiedyś potrwać dłużej, niż zakładano.
Podstawowy wpis w crontabie ma pięć pól czasu i komendę:
minuta godzina dzień_miesiąca miesiąc dzień_tygodnia polecenie
Przykłady:
*/10 * * * * /usr/bin/php /var/www/app/artisan schedule:run— uruchomienie co 10 minut,30 2 * * 1 /usr/bin/python3 /scripts/backup.py— backup w poniedziałek o 2:30,0 3 * * * /usr/bin/bash /scripts/cleanup.sh— sprzątanie plików codziennie o 3:00.
Najważniejsza zasada: Cron nie powinien wykonywać masowej pracy bezpośrednio, jeśli ta praca może trwać długo, blokować zasoby albo rosnąć wraz z liczbą użytkowników. Dobrym zadaniem dla Crona jest uruchomienie krótkiego procesu, który:
- sprawdzi, co trzeba wykonać,
- podzieli pracę na mniejsze porcje,
- zapisze zadania do kolejki,
- zakończy działanie szybko i przewidywalnie.
Zły przykład to skrypt, który co pięć minut pobiera tysiące rekordów z bazy, generuje pliki PDF, wysyła e-maile i jeszcze synchronizuje dane z API. Gdy jedno uruchomienie nie zdąży się zakończyć przed kolejnym, powstają nakładające się procesy. To jeden z najczęstszych powodów nagłych skoków użycia CPU, RAM i liczby połączeń do bazy.
W praktyce warto trzymać się kilku reguł:
- używaj pełnych ścieżek do interpreterów i plików, np.
/usr/bin/php, nie samophp, - zapisuj logi:
>> /var/log/cron-app.log 2>&1, - testuj komendę ręcznie przed dodaniem jej do crontaba,
- nie ustawiaj wielu ciężkich zadań na tę samą minutę,
- dodawaj blokadę przed równoległym uruchomieniem tego samego procesu.
Blokada może być prosta, na przykład przez flock:
*/5 * * * * /usr/bin/flock -n /tmp/import.lock /usr/bin/php /var/www/app/import.php >> /var/log/import.log 2>&1
Dzięki temu kolejne uruchomienie nie wystartuje, jeśli poprzednie nadal działa. To nie rozwiązuje problemu wydajności, ale odcina jeden z najbardziej bolesnych scenariuszy: kilka identycznych procesów mielących te same dane naraz.
Kolejka zadań daje kontrolę nad tempem pracy
Kolejka zadań jest potrzebna wtedy, gdy proces da się odłożyć w czasie i wykonać poza głównym żądaniem użytkownika. Dotyczy to między innymi wysyłki e-maili, generowania raportów, obróbki obrazów, przeliczania statystyk, synchronizacji z API, importów CSV czy tworzenia faktur zbiorczych.
Mechanizm jest prosty. Aplikacja nie wykonuje ciężkiego zadania od razu. Zapisuje je do kolejki, a osobny proces — worker — pobiera zadania i wykonuje je w tle. Źródłem kolejki może być baza danych, Redis, RabbitMQ, Amazon SQS lub inny broker. Wybór zależy od skali, wymagań i stosu technologicznego.
Największa różnica względem samego Crona polega na kontroli. W kolejce można ustawić:
- liczbę workerów,
- liczbę prób po błędzie,
- opóźnienie ponowienia,
- priorytet zadań,
- limit czasu wykonania,
- osobne kolejki dla różnych typów pracy.
To zmienia sposób myślenia o automatyzacji. Zamiast pytać „o której odpalić skrypt?”, lepiej zapytać: ile zadań serwer jest w stanie bezpiecznie przetworzyć w danym czasie?
Przykład: aplikacja ma wysłać 20 000 wiadomości e-mail po zakończeniu promocji. Cron może raz na minutę uruchomić skrypt, który doda paczki po 500 wiadomości do kolejki. Workery będą wysyłać je stopniowo, zgodnie z limitem dostawcy poczty i możliwościami serwera. Gdy API pocztowe zacznie zwracać błędy, zadania można ponowić z opóźnieniem zamiast powtarzać całą kampanię ręcznie.
Popularne frameworki mają gotowe mechanizmy do takiej pracy. Laravel Queue, Symfony Messenger, Celery w Django/Pythonie czy systemy oparte o Sidekiq w Ruby pozwalają definiować zadania jako osobne klasy lub funkcje. To wygodne, ale nie zwalnia z decyzji architektonicznych. Samo użycie kolejki nie chroni przed przeciążeniem, jeśli ustawisz zbyt dużo workerów albo wrzucisz do niej zadania bez limitów.
Przy mniejszych projektach kolejka oparta o bazę danych bywa wystarczająca. Jest łatwa do uruchomienia i nie wymaga dodatkowej usługi. Ma jednak ograniczenia: przy dużej liczbie zadań potrafi obciążać bazę, szczególnie jeśli workery często odpytują tabelę kolejki. Redis jest zwykle lepszym wyborem dla intensywnej pracy w tle, bo jest szybki i dobrze pasuje do krótkich operacji kolejkowania. RabbitMQ lub SQS mają sens tam, gdzie liczy się większa niezawodność, separacja usług i przewidywalna obsługa dużego ruchu.
Najgorsza decyzja to budowanie „kolejki” jako jednego skryptu Cron, który pobiera wszystko z tabeli pending i wykonuje po kolei bez limitów. To działa tylko do momentu, gdy danych przybędzie. Potem zaczynają się timeouty, duplikaty i ręczne czyszczenie statusów w bazie.
Limity, blokady i monitoring są ważniejsze niż sam harmonogram
Stabilny system automatyzacji nie polega na tym, że zadania „jakoś się uruchamiają”. Stabilny system ma limity. Bez nich serwer pracuje dobrze tylko przy optymistycznym scenariuszu.
Najpierw trzeba rozdzielić zadania według ryzyka:
- lekkie i częste — np. czyszczenie krótkich cache’y, odświeżanie prostych liczników,
- ciężkie i cykliczne — backupy, raporty, importy, synchronizacje,
- zewnętrzne i nieprzewidywalne — operacje zależne od API, poczty, płatności, hurtowni danych,
- krytyczne biznesowo — faktury, powiadomienia transakcyjne, aktualizacje stanów magazynowych.
Dla każdej grupy powinny istnieć inne zasady. Zadania lekkie mogą działać często. Zadania ciężkie trzeba dzielić na partie. Zadania zależne od API muszą mieć retry z opóźnieniem i obsługę limitów. Zadania krytyczne wymagają logowania błędów, alarmów i ręcznego sposobu ponowienia.
Priorytet numer jeden to ochrona przed nakładaniem się procesów. Jeśli zadanie uruchamiane co 10 minut czasem trwa 18 minut, nie wolno udawać, że wszystko jest w porządku. Do wyboru są trzy sensowne ścieżki:
- wydłużyć interwał,
- podzielić zadanie na mniejsze paczki,
- przenieść wykonanie do kolejki i ograniczyć liczbę workerów.
Dopiero potem warto optymalizować harmonogram. Rozsuwanie zadań w czasie jest proste i skuteczne. Backup o 2:00, raporty o 2:20, import o 2:45, sprzątanie plików o 3:15. Brzmi banalnie, ale w wielu projektach połowa problemów znika po usunięciu jednej minuty „0” z crontaba.
Drugim filarem jest monitoring zadań w tle. Log zapisany do pliku to minimum, nie pełna obserwowalność. Trzeba wiedzieć:
- kiedy zadanie wystartowało,
- ile trwało,
- czy zakończyło się błędem,
- ile rekordów przetworzyło,
- ile zadań czeka w kolejce,
- czy worker nadal działa.
Do pilnowania workerów często używa się narzędzi takich jak Supervisor albo systemd. Monitoring metryk można oprzeć o Prometheus, Grafanę, usługi APM albo prostsze alerty wysyłane do Slacka czy e-maila. Nie chodzi o efektowny dashboard. Chodzi o to, żeby błąd z backupem, kolejką maili albo importem danych nie wyszedł dopiero od klienta.
Trzeci element to limity na poziomie aplikacji. Dobre zadanie w tle powinno mieć określony rozmiar paczki, timeout i strategię ponowienia. Przykładowo import nie musi przetwarzać 100 000 rekordów w jednym przebiegu. Może brać po 1000, zapisywać postęp i kończyć się bez dramatu, nawet jeśli kolejny przebieg przejmie dalszą część pracy.
Warto też rozdzielać kolejki. Jedna kolejka dla maili marketingowych, druga dla zadań krytycznych, trzecia dla raportów. Dzięki temu generowanie dużego raportu nie zablokuje potwierdzenia płatności albo powiadomienia dla użytkownika. To ma większe znaczenie niż sama liczba workerów.
FAQ
Czy Cron wystarczy bez kolejki zadań?
Tak, jeśli zadania są krótkie, przewidywalne i nie rosną mocno wraz z liczbą danych. Proste czyszczenie plików, uruchomienie backupu czy wywołanie pojedynczego endpointu może działać wyłącznie przez Cron. Kolejka jest potrzebna, gdy zadanie trwa długo, wymaga ponowień, dotyczy wielu rekordów albo nie powinno blokować aplikacji.
Jak często uruchamiać zadania Cron?
Tak często, jak wymaga tego proces, ale z marginesem na najgorszy realistyczny czas wykonania. Jeśli zadanie zwykle trwa 2 minuty, ale czasem 9 minut, interwał co 5 minut bez blokady jest proszeniem się o kłopoty. Najpierw zmierz czas działania, potem ustaw harmonogram.
Ilu workerów kolejki uruchomić?
Tyle, ile serwer obsłuży bez zabierania zasobów aplikacji głównej. Na małym VPS-ie lepiej zacząć od jednego lub dwóch workerów i obserwować CPU, RAM, I/O oraz obciążenie bazy. Więcej workerów nie zawsze oznacza szybciej. Przy zadaniach intensywnie korzystających z bazy może oznaczać wolniej i bardziej awaryjnie.
Co zrobić, gdy zadanie czasem wykonuje się dwa razy?
Trzeba dodać idempotencję, czyli zaprojektować zadanie tak, aby ponowne wykonanie nie psuło danych. Przykład: przed wysłaniem faktury sprawdź, czy faktura nie została już wysłana; przed importem rekordu sprawdź jego unikalny identyfikator; przed pobraniem płatności zweryfikuj status transakcji. Sama blokada procesu nie wystarczy, bo powtórzenia mogą wynikać także z retry po błędzie.
Czy zadania w tle powinny działać w godzinach nocnych?
Nie zawsze. Noc jest dobra dla backupów, raportów i ciężkich importów, jeśli użytkownicy wtedy rzadko korzystają z systemu. Ale zadania zależne od zewnętrznych API, wysyłki e-maili albo procesów biznesowych mogą wymagać pracy w ciągu dnia. Decyzję trzeba oprzeć na ruchu aplikacji, limitach usług zewnętrznych i znaczeniu zadania.
Zacznij od sprawdzenia crontaba i znajdź zadania uruchamiane w tej samej minucie. To najszybszy test. Potem zmierz czas działania najcięższych skryptów i dodaj blokady przed równoległym startem. Jeśli którykolwiek proces przetwarza dużą liczbę rekordów albo wysyła dane do zewnętrznego API, przenieś go do kolejki i ustaw limit workerów. Najpierw usuwa się nakładanie procesów, dopiero później dopieszcza harmonogram.
