Cześć, spotkaliście się kiedyś w swojej karierze z sytuacją, że aplikacja po określonym czasie zazwyczaj po około tygodniu bardzo, bardzo spowalnia. Renderowaniu widoku zajmuję zamiast 150ms~ 4000ms. Wpierw myślałem, że problem po stronie bazy po wykorzystaniu dodatkowego logowania okazało się, że czas zapytań nie uległ zmianie, to samo z czasem wyciągania danych z cache. Dostaliśmy logi od adminów na temat wykorzystania procesora, pamięci ram. Wszystko wygląda ok, cory zazwyczaj się nudzą, zużycia maksymalne to około 30%, pamięć tak samo zużycie na poziomie 50%. Po restarcie aplikacja znowu działa stosunkowo szybko i znowu sytuacja się powtarza po kilku dniach ~6-7. Czy ktokolwiek, miałby jakiś pomysł, co można by było sprawdzić. Słowa kluczowe ASP.NET MVC, Hangfire, EF, Redis, Dużo integracji, Szczerze to nie mam pomysłu.
a probowales sprofilowac najpierw projekt?
https://www.jetbrains.com/lp/dotnet/
dotTrace i dotMemory
bez logow / konkretow ciezko wywrozyc ;)
Szklana kula mówi: memleak albo outofmemory. Zużycie pamięci na maszynie o niczym nie swiadczy bo to maszyna wirtualna (w waszym przypadku .net) decyduje ile heapu ma aplikacja. Może trzymacie przypadkiem w pamięci jakieś śmieci (in memory cache bez expire?) i zużycie heapu rośnie, aż się skończy i GC zaczyna mielić a aplikacja ma lagi.
Nie macie tam żadnych metryk zapiętych do tej aplikacji? Jak wy żyjecie? :D Myślałem że w 2020 to jest podstawa że gdzieś stoi sobie Grafana z ładnymi wykresami z metrykami biznesowymi (np. liczba requestów różnego typu) i technicznymi (czasy odpowiedzi, zużycie pamięci, cpu itd)
A skoro integracja, to w wielu miejscach jest okazja do wyciekania zasobów?
Raz mialem na produkcji, po rzędu ~100 dniach wyciekło 50tys connectionów MSSQL (Tomcat, Java w stabilnej wersji wszystkich bibliotek, na Win serwerze, pule jawoskich połączeń prawidłowo skonfigurowane, powinny się same sprzątać po tysiącu sekund, ale to nie pule padły, tylko natywne połączenia)
Miałem 3-4 dni niejasne zgłoszenia, że zwalnia, bez charakterystycznych wpisów w logach. Dopiero jak doszło do klinczu komunikat już był wyraźny. O dziwo nigdy się nie powtórzyło.
Też bym strzelał, że memleak / OOM. Tym bardziej, że sam kiedyś wkopałem się w podobny grajdołek ze skopanym zarządzaniem pamięcią - wystarczyło jedna linijka z deepcopy za dużo przed wrzuceniem tasków do puli procesów i pamięć puchła mniej więcej kwadratowo z ich liczbą. Syndromy były podobne - taski zaczynały niemiłosiernie zamulać, ale tylko dla tasków na tyle dużych, że swap wkraczał do akcji. Jeszcze większe i leciał OOM, a procesy były losowo ubijane - który pierwszy sięgnął dna wiaderka przegrywał.
Podłącz profiler i siedzieć, czekać, obserwować ;)
Jak nie masz dostępu do logów z produkcji, to zawsze możesz na środowiskach testowych wygenerować duże obciążenie (np. load testami) i sprawdzić, czy nadal będzie tak pięknie. Macie w ogóle jakieś regularne load testy?
Można zawsze walnać heapdump na produkcji przed restartem a potem go sobie analizować na spokojnie
Dużo rzadziej niż memleak może też być thread leak, a więc tworzonę są nowe wątki które nigdy się nie zatrzymują. Miałem to tylko raz na produkcji, aplikacja zaczyna się zachowywać bardzo dziwnie tak jakby JVM przestawiał czasami działać np. otwarcia plików potrafiły failować losowo.
Generalnie rada jest taka "observability", zapnij jakieś metryki do tej apki i patrz co rośnie/się zmienia po tym tygodniu. W ten sposób szybko dojdziesz gdzie jest problem. Na początek warto: pamięć, liczbę wątków, IO, CPU i Network monitorować. Jeżeli DB jest w chmurze typu AWS to metryki z DB masz za darmo, w gównianym ale darmowym CloudWatch'u...