Mam websphera. 20 warek, połączenia kolejkowe, bazodanowe, plikowe.
Zużycie zasobów rośnie jak inflacja a przez to raz na jakiś czas websphera trzeba zrestartować.
Pytanie.
W jaki sposób najlepiej szukać wiszących transakcji, połączeń zewnętrznych? Wyciekow pamięci. Macie swoje porady i narzędzia?
Pamięć. Prawie każdy profiler ma coś do analizy heap.
Najtaniej to podłączasz visualvm i robisz porównanie stert (delta) po upływie kilku minut.
Z tym, że co dalej to już bardzo specyficzne.
No i jal masz taką kupę jak websphere to może być tak, że masz też jakąś kupowatą jvm i visualvm nie podłączysz (nie pamiętam).
Zawsze można też robić zrzut heapdump i analizować toolem https://www.eclipse.org/mat/
IBM ma swoje toole https://www.ibm.com/docs/en/was/8.5.5?topic=generation-generating-heap-dumps-manually (nie pamiętam, ale możliwe, że to na koniec był ten ssm eclipse mat tylko pod inną nazwą).
Dobrze jest wyizolować scenariusz - czyli skrypt np. gatling, który Ci wywala pamięć. Może dzieje sie to na konkretnych requestach.
Co do wycieku połączeń itp.: netstat, lsof. Praktycznie każda baza pokaże ci aktywne sesje. Szukasz co w zasadzie cieknie
,...a potem... to już analiza kodu.
Jeśli musisz restartować websphera developerskiego, bo puchnie przy wrzucaniu kolejnych wersji softu - to nic nie zrobisz raczej. Całe gówniane JavaEE tak ma. A websphere chyba najgorzej.
Najlepiej to mieć profesjonalne narzędzia - np, JProfiler - (można triala ściągnąć)- polecam. W prawie każdym większym korpo stoi sobie DynaTrace - to jest mega kombajn, ale kosztuje krocie, musi być dobrze skonfigurowane, a do tego na początek ciężko się ogarnąć.
Tak, na pewno to jest błąd websphere... Ludzie, bądźmy poważni. Na 99% problem powoduje jedna z aplikacji którą masz tam odpaloną a nie żadne problemy z pulą połączeń.
Myśle że zabierasz się za to zupełnie od d**y strony. Mamy rok 2021 i powinieneś mieć metryki w jakiejś grafanie dla każdej z aplikacji i nie trzeba by cudować i zgadywać, tylko wyświetlić sobie wykresy zużycia zasobów dla tej konkretnej aplikacji i byłoby wiadomo co się dzieje. No ale skoro tego nie masz, to najprościej będzie odpalić na jakimś testowym serwerze te twoje aplikacje osobno, tak żeby znaleźć tą która powoduje problem, a potem zapiąć do niej jakiś VisualVM i sprawdzić jakie obiekty powodują problem. Znając życie jakieś Map<K,V> w kodzie puchnie bo ktoś chciał sobie zrobić cache i nie pomyślał o tym, że trzeba je czasem czyścić.
W Twojej sytuacji, na ile instancji JVM rozłożone jest te 20 war'ów (innymi słowy ile serwerów WS jest wykreowanych w ramach instalacji WS)?
Jeśli na 1 to słabo, bo 1 gó****na aplikacja będzie wpływać na pozostałe. Jeśli w ramach WS, masz faktycznie 1 serwer, to możesz:
W końcu zostajesz z 1 aplikacją i np. odkrywasz, że ustawiłeś jakiś session timeout na 3600 myśląc, że to sekundy, a to były minuty...
Ogólnie w takich problemach staram się:
A) zadać kilka prostych pytań i zrozumieć tło sytuacji.
bleedeing edge patch dla WS, po aktualizacji kernela, po hot fixie aplikacji X, ... )B) zrozumieć w jakim stanie jest serwer, na którym jest WS zainstalowany
C) analizować proces, który jest problematyczny
Zazwyczaj dedykowane narzędzia (np. do bazy danych, do JVM, )
Czasem ogólne narzędzia - strace, pstack, perf, ...
Analiza ma na celu zrozumienie gdzie są "waity" , jak wygląda "łańcuch oczekiwania" i ile czasu trwa obsługa żądań do zasobu.
Jak już wiadomo co jest na początku łańcucha, to ten proces brany jest za cel do dalszej analizy.
Możesz podpiąć się pod JVM jakimś toolem wspomnianym przez @jarekr000000 czy @Shalom i zobaczyć co się dzieje. Tylko, do której instancji JVM? Chyba, że masz 1, to wtedy patrz początek posta :-)