Linux działa dobrze w testach, ale zwalnia w produkcji

Na testach wszystko wygląda idealnie: CPU ma zapas, RAM się mieści, odpowiedzi API są szybkie. Potem wchodzi realny ruch i po dwóch godzinach użytkownicy zgłaszają „mulenie”, timeouty i losowe błędy 502. Z perspektywy zespołu to najgorszy scenariusz: dashboardy nadal zielone, a biznes już widzi spadek konwersji i rosnącą liczbę zgłoszeń.

To nie jest anomalia. To standardowy efekt różnicy między ruchem laboratoryjnym a produkcją, gdzie requesty nie są równe, użytkownicy nie zachowują się przewidywalnie, a wiele komponentów walczy o te same zasoby. W praktyce takie przypadki najczęściej wychodzą podczas stałego utrzymania, które łączy system, aplikację i warstwę usług w jeden model operacyjny, zamiast rozdzielania ich na silosy typu „to na pewno nie u nas”.

CPU nie jest problemem, dopóki nie spojrzysz na iowait i scheduler

Najczęstszy błąd to patrzenie wyłącznie na „CPU usage”. Serwer pokazuje 45%, więc teoretycznie ma zapas. W rzeczywistości użytkownik czeka, bo procesy blokują się na I/O.

W incydentach produkcyjnych regularnie widać ten sam wzorzec:

  • load average rośnie szybciej niż użycie CPU
  • iowait podbija się skokowo przy piku ruchu
  • run queue wydłuża się, mimo że CPU nie jest wysycone

To moment, w którym scheduler staje się wąskim gardłem. Procesy aplikacji, workerzy bazy, zadania systemowe i operacje I/O konkurują o czas CPU.

Z zewnątrz wygląda to jak „niewyjaśnione lagi”. W praktyce to klasyczny przypadek: CPU wygląda dobrze, ale system nie nadąża z obsługą zadań.

Dysk: opóźnienie zabija szybciej niż brak IOPS

W benchmarku dysk daje dobre wyniki, bo test jest czysty i przewidywalny. W produkcji pojawia się miks operacji: losowe odczyty, fsync, logi, rotacje, snapshoty.

Problemem nie jest liczba IOPS, tylko stabilność latencji.

Użytkownik odczuwa p95 i p99, nie średnią. Wystarczy, że opóźnienie skacze z 2 ms do 50 ms, żeby:

  • baza zaczęła czekać
  • aplikacja czekała na bazę
  • kolejki requestów zaczęły rosnąć

W logach pojawia się wtedy charakterystyczna sekwencja:

  • wydłużone zapytania do DB
  • rosnący upstream response time
  • później timeouty i 5xx

System nadal działa. Użytkownik już nie.

Pula połączeń: problem, który wygląda jak losowy chaos

Źle dobrana pula połączeń nie psuje systemu od razu. Najpierw:

  • rośnie czas oczekiwania na wolne połączenie
  • requesty zaczynają się kolejkować
  • pojawiają się timeouty

Testy obciążeniowe rzadko to wychwytują, bo używają jednej ścieżki. Produkcja ma nierówny ruch, różne endpointy i zmienne czasy odpowiedzi.

Efekt jest powtarzalny: krótki pik ruchu powoduje długi ogon opóźnień. System wraca do normy po kilku minutach, ale użytkownik już odczuł problem.

Noisy neighbor i lock contention

W środowisku współdzielonym wydajność może spaść bez żadnej zmiany po Twojej stronie.

  • backup na tym samym storage
  • job analityczny
  • snapshot VM

To wystarczy, żeby podnieść latencję całej platformy.

Do tego dochodzi lock contention: transakcje blokują się na tych samych danych. Na wykresach wszystko wygląda poprawnie, a użytkownik czeka.

To dokładnie ten typ problemu, który nie wychodzi w testach syntetycznych.

Sieć: problem, którego nie widać na wykresie interfejsu

Brak dropów na interfejsie nie oznacza, że sieć jest zdrowa.

Problemy siedzą wyżej:

  • retransmisje TCP
  • kolejki na load balancerze
  • DNS pod presją
  • timeouty między usługami

Efekt: „czasem działa, czasem nie”.

To najdroższy typ problemu operacyjnego, bo jest trudny do odtworzenia i kosztuje czas zespołu.

Dlaczego metryki są zielone, a biznes widzi czerwone

Większość monitoringu opiera się na średnich i progach.

Problem: degradacja zaczyna się w:

  • percentylach (p95/p99)
  • kolejkach
  • czasach oczekiwania

Z perspektywy biznesu oznacza to:

  • spadek konwersji
  • więcej ticketów
  • rosnący koszt obsługi
  • pogorszenie SLA

Dlatego realna wydajność Linux w produkcji nie wynika z „czy serwer żyje”, tylko z tego, jak szybko użytkownik dostaje odpowiedź.

Wniosek: test to obietnica, produkcja to prawda

Benchmark mówi, co system potrafi w idealnych warunkach.

Produkcja pokazuje, ile z tego dowozisz użytkownikowi w realnym ruchu.

Największy problem nie polega na tym, że system się psuje.

Problem polega na tym, że przez długi czas wygląda na zdrowy.

Jeżeli metryki mówią „jest dobrze”, a użytkownik mówi „jest wolno” — to zwykle użytkownik ma rację.