GC, K8S, kilka pytań.

Mam serwis w netcore generujący raporty. Chcialem przetestować jak sie zachowa przy sporej liczbie strzałow, ale synchronicznie, po kolei. Mam problem z pamięcią
I tak.
Apka odpalona w VS, zajetość ramu powoli rośnie, co kilkanascie sekund wlacza sie GC, ale generalnie rośnie i rośnie. Mam dużo ramu wiec nie chcialo mi sie czekac co sie stanie az cały zeżre.
Apka odplalona w kontenerze Dockera, ustawiony limit pamieci. Po osiągnięciu 100% uzycia ramu, spada do 99% i tak sie wacha w przedziale 99-100. Apka dziala normalnie, dostaje prawidlowe odpowiedzi, nie wiem jednak co sie tam dzieje, jak czesto gc jest wolany, nie udalo mi sie poki co podpiac z debuggerem (dostaje komunikat ze brak praw zapisu do kontenera, jutro jeszcze spróbuje)
Finally, apka odpalona w K8S(GKE). 2 pody, ustawiony limit pamieci 512mb per pod (razem 1gb). Po osiągnięciu 512mb przez pod, pod sie restartuje.

Pytania:

1. Czy to jest normalne zachowanie k8s, tzn te restarty podów po osiagnieciu limitu? Mozna to zmienić zeby sie nie restartowaly?
2. Jak kontener "widzi" dostępną pamięć? Widzi ze ma dostępne 512 czy jednak te 1gb dla calego deploymentu?
3. Czy w momencie restartu poda jakis request może sie "zgubić" tzn dostać jakąś 500'tke bo trafił akurat na moment restartu? Testowalem przy 10k requestów, był kilkakrotnie restart podów, niby zawsze dostawalem status 200, ale może mialem tylko farta? Nie bolały by mnie te restarty gdybym mial pewnosc ze wszystkie requesty dostaną prawidlową odpowiedz.
4. Jak by można zdiagnozować ten potencjalny memory leak? Zapuszczalem to narzedzie z VS ktore pokazuje liczbę obiektów (.NET object allocation) i liczba obiektów rośnie, odpala sie gc, spada - generalnie utrzymuje sie caly czas na tym samym poziomie. Skąd wiec ten przyrost pamieci skoro liczba obiektów wlasciwie jest caly czas taka sama?

pliz halp

kzkzg napisał(a):

Pytania:

1. Czy to jest normalne zachowanie k8s, tzn te restarty podów po osiagnieciu limitu? Mozna to zmienić zeby sie nie restartowaly?

Normalne - https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits. I z tego co wiem nie da się tego zmienić (ale zawsze możesz nie ustawiać limitu :P).

2. Jak kontener "widzi" dostępną pamięć? Widzi ze ma dostępne 512 czy jednak te 1gb dla calego deploymentu?

Kontener powinien widzieć 512 MB, bo limity ustawiasz na poziomie poda/kontenera a nie deploymentu.

3. Czy w momencie restartu poda jakis request może sie "zgubić" tzn dostać jakąś 500'tke bo trafił akurat na moment restartu? Testowalem przy 10k requestów, był kilkakrotnie restart podów, niby zawsze dostawalem status 200, ale może mialem tylko farta? Nie bolały by mnie te restarty gdybym mial pewnosc ze wszystkie requesty dostaną prawidlową odpowiedz.

Może się zgubić.
Możesz spróbować ustawić hooka preStop i tam dać jakiś sleep (czyli powiedzmy że to taki connection draining).
O ile w przypadku przekroczenia limitu pamięci ten hook się wywoła (ale obstawiam, że jednak powinien).

4. Jak by można zdiagnozować ten potencjalny memory leak? Zapuszczalem to narzedzie z VS ktore pokazuje liczbę obiektów (.NET object allocation) i liczba obiektów rośnie, odpala sie gc, spada - generalnie utrzymuje sie caly czas na tym samym poziomie. Skąd wiec ten przyrost pamieci skoro liczba obiektów wlasciwie jest caly czas taka sama?

Może spróbuj https://devblogs.microsoft.com/dotnet/collecting-and-analyzing-memory-dumps/.

Dzięki za odpowiedz

Może się zgubić.

Gdzieś o tym przeczytałeś czy wiesz z praktyki?

Rozumiem ze podczas tego preStop ruch juz nie jest kierowany na tego poda ?

kzkzg napisał(a):

Dzięki za odpowiedz

Może się zgubić.

Gdzieś o tym przeczytałeś czy wiesz z praktyki?

Z praktyki przy RollingUpdates.
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination

Rozumiem ze podczas tego preStop ruch juz nie jest kierowany na tego poda ?

Tak.