Długie pauzy aplikacji

Mam problem z aplikacją która długo działa. Co jakiś czas są zatrzymania aplikacji na około 5sekund spordycznie zdazalo sie na 30-120 sekund. Na razie nie wygląda to na wyciek pamięci (robiłem dumpa pamieci), użyty heap oscyluje około 50-70% dostępnej pamięci. Przydzielone dla javy mam min 8Gb max 10Gb, maszyna ogólnie ma 16Gb ramu. Przeglądając GC log wygląda jakby powodem bylo przerzucanie obiektów z young generation do tenured generation.

Przestój 5sekundowy pojawił się po zwiększaniu heap size do 10gb (żółty obszar widoczny na screenie).
Niebieski to used heap size.
Fioletowy/rozowy to Tenured generation, momenty skoków nakładają się ze spadkami young generation (young niestety nie widac na obecnym screenie).
Czerwony oraz zielony to czas GC.

Jak widać od momentu skoku nie pracuje juz tak regularnie jak przed.
Na maszynie nie widać jakiś dużych obciążeń IO czy CPU. Ramu obecnie wolnego na maszynie jest około 10-15%.
Wersja javy to 8u201.

Może ktoś miał podobny problem i ma jakies wskazówki? Dodam iż aplikacja przetwarza sporo danych wiec przemiał różnego typu obiektów jest spory.
Mam ustawioną JVM aby korzystała z GC1, -server oraz -UseMembar.

To jest twoja aplikacja? Mozesz cos w niej zmieniac?
Wolny RAM na poziomie 10-15% to malutko, moze Ci system swapowac.
Jak nie mozesz tej apki optymalizowac to dodaj RAM, niekoniecznie zmieniajac parametry jvm (to w drugiej kolejnosci).

jak jest problem z GC, to zwiększenie heapa zwiększa problem, to normalne.

Co ci go zajmuje? Jakaś wielka cache "in heap" ?

Doradzić ... ja bardzo pilnuję, aby np w wewnętrznych pętlach nie mnożyć sztuk obiektów ponad potrzebę, a najlepiej wcale (na prymitywach)
Stringi sklejasz plusami?
Którejś z twoich klas jest w heapie szczególnie dużo? Bo String'a będzie na pewno dużo.
Czyli to jeden z mniejszościowych dziś zagadnień, ze mikrooptymalizacja na sens, ale nie na tyle CPU, a na sztuki obiektów.
Poszukaj m.in. na YT "low latency java"

Jakieś verbose logi z aktywności GC możesz wystawić?

aby korzystała z GC1, -server oraz -UseMembar. -

to pierwsze powinno powodować, że nie masz duzych pauz (a masz odnotowane 2.7s pauzy ) trochę to śmierdzi - jesteś pewny, że G1GC działa.
-server masz ustawione niepotrzebnie - ta flaga jest ignorowana.
-XX:+UseMembar- to jest bardzo ciekawe. Why?

Kopiowanie obiektów raczej nie jest aż takie zasobożerne. IMO masz albo memory leaka, albo jakiś nieefektywny algorytm, albo zbyt mało pamięci - widać, że w momencie gdy zaczyna brakować miejsca na OldGen to GC zaczyna odpalać się raz po raz i nie może odzyskać pamięci.

Dodatkowo tak jak już tu wspomniano - sprawdź, czy nie robi ci się swap.

No i może podaj cały command line którego użyłeś do odpalenia apki.

Źródeł nie moge udostepnić niestety. Ogolne zadanie aplikacji to odbior danych po tcp i proba dekodowania odebranych byte[] na konkretne obiekty i zapis ich do bazy.
Aplikacja jest odpalana komendą:

java -Djava.library.path=*** -server -XX:+UseG1GC -XX:+UseMembar -Xms8g -Xmx10g -Djava.net.preferIPv4Stack=true -jar ***.jar

@maniek41: długie te dane w byte? I całe dekodowanie jest zrobione w jednej funkcji może?

@jarekr000000: dekodowanie jest rozbite na kilka metod, ale rozmiar tablic bajtowych do dekodowania na jeden obiekt moze sie wahać od kilku kb, mb do nawet 4gb (tak duzy raz na kilka dni)

Generalnie nie rozumiem ekranu, który pokazujesz (nie wiem co on dokładnie pokazuje - lepsze by były logi GC). Z ekramu wynika, że jest jakaś długa pauza, która jednak nie jest pauzą na gc (dziwne).
Widzę dwie opcje:
a) pragram nie rozumie logu G1GC i pokazuje bzdury - nie ma żadnej pauzy
b) pauza jest, bo masz problem z safepoint - aplikacja coś liczy i długo czeka na safeponit - dopiero potem odpala się GC

jeśli b) to dooglądaj/doczytaj co to są safepointy i zobacz czy nie masz tego problemu (choć to całkiem trudne w diagnozie - profilery w większości będą Cię okłamywać),
uruchom na jakimś nowszym Jvm - im nowszy tym lepiej (ale minimum java 13) - jeśli dużo się zmieni - to może to było źródłem problemu

@jarekr000000: Po podniesieniu wersji javy i przekompilowaniu (próby uruchomienia były na 13,14,15) rozjechało się coś z przetwarzaniem danych odbieranych z TCP bo nie potrafił ich zdekodować, więc chyba ta opcja odpada.
Sprawdze jeszcze temat z safepoint'ami.

maniek41 napisał(a):

Wersja javy to 8u201.

A szkoda. A z 11 próbowaliście?

Conclusion
Java 11 brings additional improvements, which vary across different OptaPlanner examples and data sets. On average, it is 4.5% faster when using Parallel GC and 16.1% faster with G1 GC. Despite the significant improvement for G1 GC, Parallel GC is still faster for most data sets in this benchmark.

https://www.optaplanner.org/blog/2019/01/17/HowMuchFasterIsJava11.html

No poza udoskonalonym G1C masz dodatkowe opcje do przetestowania jak ZGC (mega krótkie pauzy ale żre dużo pamięci - taki trade-off)

throughput-latency-footprint tradeoff. When choosing between these 3 things, you can only pick 2.
ZGC is a concurrent GC with low pause times. Since you don't want to give up throughput, you trade latency and throughput for footprint. So, there is nothing surprising in such high memory consumption.
G1 is not a low-pause collector, so you shift that tradeoff towards footprint and get bigger pause times but win some memory.

Do badania safepointów są jakieś flagi: https://plumbr.io/blog/performance-blog/logging-stop-the-world-pauses-in-jvm

Poza tym (nie sprawdzałem jak działają, ale) można skorzystać z JFR (Java Flight Recorder) i JMC (JDK Mission Control). Nie wiem jakie dane zbierają, ale można sprawdzić.

Co do safepointow -> jest jeszcze takie cos co sie nazywa time to safepoint.

Jak ktos chce cos wiecej o safepointach itp: http://psy-lob-saw.blogspot.com/2015/12/safepoints.html