Problem ze zbyt duża liczbą watków NotifyHandshakeThread zabija produkcje

0

Witam,
mamy dziwną sytuacje na produkcji możliwe ze ktoś się spotkał z czymś takim....
Serwer Wildfly 10 JDK 8 otóż w niektórych momentach widzimy spory przyrost wątków +500 w ciągu 10 minut sun.security.ssl.SSLSocketImpl$NotifyHandshakeThread co w rezultacie prowadzi do błędu "Too many open files" oczywiście możemy zmienić parametr w linux który umożliwi Java'ie otworzenie większej ilości soketów jednak dlaczego tych wątków jest tak dużo, wszystkie wskazują na ten sam adres dodatkowo dlaczego się nie kończą. ThreadDump pokazuje tylko że wątek sun.security.ssl.SSLSocketImpl$NotifyHandshakeThread jest w stanie RUNNABLE ale nie ma stacktrace

0

A czy poza tym nie macie dużo wątków? Bo widzę tam w kodzie JDK szanse na Starvation.
czy nie brakuje troche pamieci? GC nie walczy o życie?

0

Wszystkie te 500+ wątków dotyczy SSL handshaking? I jaka jest charakter tego SSLa? Serwer wystawia coś po SSLu, czy appka na JBossie występuje w roli klienta i coś woła?

Te wątki od notyfikacji, że ssl handshaking się zakończył sugerują, że może (czysta spekulacja) następuje próba połączenia z appki@Jboss do jakiegoś serwisu (over SSL), który to serwis ma ograniczoną pulę wątków, które wolno przetwarzają. W efekcie na JBossie połączenia "wiszą" (dobrze byłoby zobaczyć z poziomu OS utworzone sockety i ich stan) w oczekiwaniu na zakończenia SSL handshake i przetworzenie kolejnego requestu przez zdalny serwis.

Ciekawy problem do analizy :-)

0

@jarekr000000: wątków w samym jboss mamy około 400 bez tych nieszczesnych SSl, pamięci jest oki monitorujemy parametry
@yarel z tego co się dowiedziałem to wygląda to coś ala new URL("https://adres") i z tego zawartość, czyli serwer uderza do jakiegoś zasobu

0

A jesteś pewny że to nie problem wersji JVMa? Bo kojarze że było kilka takich problemów z SSLem, jakieś deadlocki i leaki.

0

@Szczery: a co w aplikacji triggeruje te strzały do https://serwera? To jakieś skolejkowane/zaplanowane joby? Czy raczej reakcja aplikacji na przychodzące requesty?

  • Może planujecie zadania do wykonania na określony dzień ?
  • Może są momenty, że w poniedziałki o 6 leci jakiś batch i strzela do Waszej aplikacji, która uderza do innego serwisu?

Stąd wzrost ilości wątków.

  • Czy zewnętrzny serwis odpowiada wystarczająco szybko jak na Wasze potrzeby i jaki "peak" jest w stanie unieść?

Możliwe, że jest jakiś skok w ilości requestów do wykonania i zewnętrzny serwis nie jest w stanie tego unieść w zakładanym czasie.

0

Te 400 wątków normalnych to sporo. Raczej macie coś chorego lub mocno nietypowego jeśli wam tyle potrzebne.
Ten brack strack trace daje do myślenia (może tez być błedem w JVM lub threaddumpie)
Co może się dziać (tylko gdybam)

  • za dużo wątków i te nowo tworzone przez SSL nie mają szansy wystartować - są tworzone, ale do run() nie dochodzi. Czekają sobie cierpliwe w kolejce do procka (może inne watki mają wyższy priorytet),
  • wątki zrobiły co swoje i wisza jako zombie - czekają aż JVM je zakończy, ale z powodu obciążenia na innych wątkach nie są zwalniane (dziwaczna hipoteza, ale i dziwaczne obserwacje),
    i cała masa podobnych scenariuszy.

Warto by sytuację zreprodukowac w labie, albo podłączć jakis lepszy monitoring (co nic nie gwarantuje).

1
Szczery napisał(a):

Witam,
mamy dziwną sytuacje na produkcji możliwe ze ktoś się spotkał z czymś takim....
Serwer Wildfly 10 JDK 8 otóż w niektórych momentach widzimy spory przyrost wątków +500 w ciągu 10 minut sun.security.ssl.SSLSocketImpl$NotifyHandshakeThread co w rezultacie prowadzi do błędu "Too many open files" oczywiście możemy zmienić parametr w linux który umożliwi Java'ie otworzenie większej ilości soketów jednak dlaczego tych wątków jest tak dużo, wszystkie wskazują na ten sam adres dodatkowo dlaczego się nie kończą. ThreadDump pokazuje tylko że wątek sun.security.ssl.SSLSocketImpl$NotifyHandshakeThread jest w stanie RUNNABLE ale nie ma stacktrace

Trudno wyrokować co tam się dzieje pod spodem. Może być tak, że:

  • po prostu jeden request generuje N połączeń do zewnętrznych usług. Jeśli N jest odpowiednio duże to będziesz miał skoki połączeń.
  • wariacja poprzedniego - jeśli jakiś wątek nie może się dobić do usługi zewnętrznej to zaczyna podbijać co chwilę a stare połączenia nie są zamykane.
  • JVM nie wyrabia z obsługą - po prostu w pewnym momencie się zapycha i połączenia stoją
  • jakiś bug w bibliotece
  • jakiś bug w JVM

Polecam sprawdzić w tej kolejności. Z doświadczenia wiem, że bugi w JVM lub bibliotekach się zdarzają, ale zdarzają się dużo rzadziej niż błędy programistów zeń korzystających :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1