GC pause na żądanie

Jakieś pomysły jak w prosty sposób namówić JVM do zrobienia GC stop-the-world na określony czas? np. 10 sek, minutę, itp. ?

A po co chciałbyś to zrobić?

w sensie chcesz wywolac GC? https://stackoverflow.com/questions/1481178/how-to-force-garbage-collection-in-java ?
BTW watpie zeby stop-the-world mogl trwac az minute

Czy możesz rozwinąć? Co chcesz osiągnąć? Wiesz jak działa GC? Nie wystarczy?

kill -SIGSTOP PID
kill -SIGCONT PID

Strzelam, że to xy problem.
Ale może pytasz o to?
https://docs.oracle.com/javase/8/docs/jdk/api/jpda/jdi/com/sun/jdi/VirtualMachine.html#suspend--

(Interface dla debuggerów)

Tak, to X/Y.

Analizuję problem pt. "losowe timeouty do serwisu X" w ramach testów wydajnościowych w środowisku hybrydowym (trochę aplikacji na k8s, trochę na wirtualkach). Przy 10k TPS leci np. 5-7 timeoutów na milion requestów i te timeouty są problemem. Koledzy z offshoru bardzo się przywiązali do koncepcji "trzeba tunować serwis X, bo wyraźnie widać, że mamy w logach time out i to nie problem u nas". Tymczase, serwer z tym serwisem bardzo się nudzi (obciążenie podczas testów: 5-10% CPU, brak waitów na I/O, brak błędów serwisu, timeoutów itp.). Aplikacja kliencka w Javie, więc mam taką hipotezę roboczą "GC pause czasem trwa > timeout na wywołanie serwisu i dlatego dostajecie losowe timeouty w komunikacji z serwisem X".

Nie mam żadnych dostępów do serwerów, wszystko odbywa się na zasadzie interakcji przez human-interface-over-teams:

• Ja "Now, type: ls <and press enter>" ,
• Interefejs: "Oooooh, it tells:
  ls: cannot access 'and': No such file or directory
  ls: cannot access 'press': No such file or directory
  ls: cannot access 'enter': No such file or directory
  "
  ...

Dlatego szukam prostego sposobu, żeby sobie po stronie klienta wygenerowali symulację GC pause i zobaczyli co im się pojawi w logach i na jaką skalę. Jak uwierzą w GC, to może nawet będą zainteresowani włączeniem logowania GC (póki co czekam cały dzień na info o wersji jvm ;-) ) i skorelowania tego z momentami timeoutów.

Te timeouty domyśłnie na http są na poziomie wielu sekund - więc może być tak, że GC (czy po stronie klienta, czy serwera) nie jest problemem. Może wstają serwisy na k8s i jest healthcheck średnio skonfigurowany (np. pierwszy prawdziwy request (nie health) trwa cholernie długo). Tony rzeczy może być problemem.

Tak, przyczyn może być wiele, ale testy przechodzą warmup, więc pody są wygrzane przed zapuszczeniem właściwego workloadu. Serwisem X w tym przypadku jest znana implementacja LDAPa w C.

Póki co, podejrzewam klienta :D Na serwerze, bufor Send-Q dla interefejsu sieciowego, po którym leci ruch od klienta, sugeruje, że klient niewystarczająco szybko odczytuje pakiety TCP (brak ACK). Jeśli to JVM, to bufor Recv-Q na kliencie powinien to potwierdzać (no ale na takie dane to poczekam sobie).

Jeżeli podjerzewasz GC to włącz sobie rozszerzone logi GC, wtedy dostanisz całe drzewo operacji które GC wykonuje i będzie od razu widać czy to GC czy nie GC, oraz jeśli to GC to co dokladnie (string dedup, czekanie na safepoint, dużo pamięci do zwolnienia itp).

Timeout w systemie rozproszonym to normalna rzecz o ile występuje w niewielkiej ilości. To mogą być problemy z DNS, problemy z siecią, problem z k8s lub zasobami, problem z dostawcą chmury, problem z Kafką itp. Jeżeli coś nie może zwrócić błędu bo timeout to należy stosować wzorce takie jak saga z retry, lub po prostu zwykłe retry lub przetwarzanie async (klient dostaje tylko status operacji a wynik może odebrać w innym endpointcie).

0xmarcin napisał(a):

Jeżeli podjerzewasz GC to włącz sobie rozszerzone logi GC, wtedy dostanisz całe drzewo operacji które GC wykonuje i będzie od razu widać czy to GC czy nie GC, oraz jeśli to GC to co dokladnie (string dedup, czekanie na safepoint, dużo pamięci do zwolnienia itp).

Timeout w systemie rozproszonym to normalna rzecz o ile występuje w niewielkiej ilości. To mogą być problemy z DNS, problemy z siecią, problem z k8s lub zasobami, problem z dostawcą chmury, problem z Kafką itp. Jeżeli coś nie może zwrócić błędu bo timeout to należy stosować wzorce takie jak saga z retry, lub po prostu zwykłe retry lub przetwarzanie async (klient dostaje tylko status operacji a wynik może odebrać w innym endpointcie).

może zacznij czytać

Dlatego szukam prostego sposobu, żeby sobie po stronie klienta wygenerowali symulację GC pause i zobaczyli co im się pojawi w logach i na jaką skalę. Jak uwierzą w GC, to może nawet będą zainteresowani włączeniem logowania GC (póki co czekam cały dzień na info o wersji jvm ) i skorelowania tego z momentami timeoutów.