Dla tych, którzy czytali o kontenerach i Dockerze , ale nie rozumieją, w jaki sposób Java przyczepiła się do kontenerów. Na początek odświeżmy sobie pamięć o pamięci Java . Przypomnę, że pamięć składa się ze stosu i sterty, które wykorzystują pamięć RAM (pamięć o dostępie swobodnym) serwera; mówiąc dalej o pamięci, będziemy mieli na myśli pamięć RAM. Przyjrzyjmy się teraz kontenerowi w przekroju. Nie, oczywiście, że nie, nie interesuje nas zad i uda, przyjrzymy się strukturze pamięci w pojemniku. Można ją podzielić na trzy części: • Pamięć sterty – sama sterta; • Off Heap to wszystko, czego nie ma na stercie; • Narzut systemu operacyjnego to narzut pamięci związany z wdrażaniem procesów wewnątrz kontenera. Powiedzmy: Do kontenera przydzieliliśmy 1 Gb, na rysunku będzie to Container Limit - jego granice oznaczono niebieskim prostokątem. Przeznaczyliśmy 80%, czyli 0,8 Gb, na pamięć Java w kontenerze, a Heap zajął nam około 80% kontenera, czyli niewiele mniej niż 0,8 Gb, ponieważ OS Overhead przejął część zasobów (narzut) do utrzymania procesów. Około 20% kontenera pozostaje na wszystko, co nie jest połączone ze stertą ( Off Heap ). Obszar Używany na rysunku pokazuje obszar pamięci używany do uruchamiania aplikacji. Teraz musimy porozmawiać o sytuacjach, w których może zabraknąć pamięci w kontenerze. OutOfMemoryError Jeśli zużycie pamięci przez aplikację ( Used area ) osiągnie limit sterty ( Heap ), wyłapiemy OutOfMemoryError (OOM Error) . Co mówi, że nie ma wystarczającej ilości miejsca na stercie, a mianowicie w obszarze pamięci, w którym umieszczane są obiekty utworzone programowo w aplikacji. Jeśli nie jest to jeszcze całkowicie jasne, wyjaśnię to w kotach. OOM Błąd jest wtedy, gdy kot długo, długo krzyczy przed drzwiami na balkon, a gdy te drzwi są otwarte, staje w progu i nie idzie w żadną stronę, często mówi się, że kot jest zamrożony. Jeśli popchniesz go na czas, opadnie szczęka i wyjdzie na balkon, aby zająć się swoimi kocimi sprawami. OOM Killer To kolejna sytuacja, która może wydarzyć się w kontenerze, gdy skończy się pamięć.Jeśli program wydostanie się poza kontener, otrzymamy OutOfMemory Killer (OOM Killer) - jest to proces, który kończy działanie aplikacji, aby uchronić jądro przed awarią. Poświęca aplikację, aby utrzymać działanie kontenera. To nie fakt, że kontener spadnie, ale aplikacja, która w nim działa, na pewno spadnie. Dzieje się tak, jeśli pozostawisz niekontrolowane zużycie pamięci przez aplikację Java. Znowu o kotach. Jeśli w sobotę zdecydowałeś się pospać dłużej i zapomniałeś dać kotu jedzenie, to OOM Killerkwiaty są gwarantowane, doniczki nie mogą zostać uszkodzone, ale kwiaty będą musiały zostać przesadzone. Jaka jest różnica między błędem OOM a zabójcą OOM? Możesz przetworzyć OOM Error i wykonać pewne czynności (na przykład: przeskalować aplikację), a OOM Killer po prostu zabije cały proces. OOM Killer jest podobny do kill-9 (kill minus dziewięć) - polecenia, które zabija proces w Linuksie . Rzecz w tym, że najpopularniejszą implementacją kontenera jest kontener Docker , który bazuje na Linuksie , nawet jeśli uruchomimy go pod Windowsem , jądro i tak będzie z Linuksa . W Linuksie interesuje nas jedno pojęcie: CGroups (angielska grupa kontrolna) - mechanizm jądra Linuksa, który ogranicza i izoluje zasoby obliczeniowe (procesor, sieć, zasoby pamięci, zasoby we/wy) dla grup procesów. Mówiąc najprościej, mechanizm ten pozwala na zarządzanie zasobami znajdującymi się w kontenerze, w naszym przypadku pamięcią. Jak Java ma się do tego? To dzięki mechanizmowi CGroups Java może zatrzasnąć się w pamięci kontenera. Ale to wszystko zależy od wersji Java. Na przykład Java 7 nie wie, jak używać CGroups i nie są jej znane limity kontenerów. Domyślnie maksymalny rozmiar sterty = ¼ pamięci fizycznej. Jeśli aplikacja przekroczy limity kontenerów to nastąpi OOM Killer , a jeśli limity kontenerów nie zostaną ustawione to aplikacja będzie pobierać pamięć od innych aplikacji na serwerze (lepiej ustawić limity, inaczej wszyscy stracą) . Możesz oczywiście użyć ustawień sterty lub użyć specjalnych „obrazów”, które rozwiązują ten problem, ale najłatwiejszym sposobem jest użycie poprawnej wersji Java. Poprawne wersje zaczynają się od Java 8 x131 (przeniesione z Java 9), zaczynają rozumieć CGroups . A w Javie 10 pojawiła się obsługa kontenerów: UseContainerSupport , później ta funkcja została przeniesiona na Javę 8 x 191 . Możesz też po prostu użyć Java: 11+ . Co można stwierdzić: Podczas korzystania z pamięci kontenera może zostać wyświetlony komunikat OutOfMemoryError (błąd OOM) lub OutOfMemoryKiller (OOM Killer). W pierwszym przypadku aplikacja nie ulegnie natychmiastowej awarii, błąd OOM można wychwycić, przetworzyć i podjąć kontrolowane działania. Na przykład skaluj aplikację. Jeśli wystąpi OOM Killer, aplikacja natychmiast się zawiesi i nie będzie możliwości jej zapisania. A najgorsze jest to, że na zewnątrz sam pojemnik będzie w porządku, to znaczy możesz nawet nie podejrzewać, że coś tam spadło. Mechanizmy systemu Linux służą do interakcji z kontenerem i pamięcią Java. Ale nie każda Java je implementuje. Aby uniknąć problemów z Javą 8, musisz użyć wersji zaczynającej się od 131 lub jeszcze lepiej od 191. Lub użyj Java: 11+. Dla praktyki: OutOfMemoryError: złap go, jeśli potrafisz
Nie, oczywiście, że nie, nie interesuje nas zad i uda, przyjrzymy się strukturze pamięci w pojemniku. Można ją podzielić na trzy części: • Pamięć sterty – sama sterta; • Off Heap to wszystko, czego nie ma na stercie; • Narzut systemu operacyjnego to narzut pamięci związany z wdrażaniem procesów wewnątrz kontenera. 
Powiedzmy: Do kontenera przydzieliliśmy 1 Gb, na rysunku będzie to Container Limit - jego granice oznaczono niebieskim prostokątem. Przeznaczyliśmy 80%, czyli 0,8 Gb, na pamięć Java w kontenerze, a Heap zajął nam około 80% kontenera, czyli niewiele mniej niż 0,8 Gb, ponieważ OS Overhead przejął część zasobów (narzut) do utrzymania procesów. Około 20% kontenera pozostaje na wszystko, co nie jest połączone ze stertą ( Off Heap ). Obszar Używany na rysunku pokazuje obszar pamięci używany do uruchamiania aplikacji. Teraz musimy porozmawiać o sytuacjach, w których może zabraknąć pamięci w kontenerze. OutOfMemoryError Jeśli zużycie pamięci przez aplikację ( Used area ) osiągnie limit sterty ( Heap ), wyłapiemy OutOfMemoryError (OOM Error) . Co mówi, że nie ma wystarczającej ilości miejsca na stercie, a mianowicie w obszarze pamięci, w którym umieszczane są obiekty utworzone programowo w aplikacji. 
Jeśli nie jest to jeszcze całkowicie jasne, wyjaśnię to w kotach. OOM Błąd jest wtedy, gdy kot długo, długo krzyczy przed drzwiami na balkon, a gdy te drzwi są otwarte, staje w progu i nie idzie w żadną stronę, często mówi się, że kot jest zamrożony. Jeśli popchniesz go na czas, opadnie szczęka i wyjdzie na balkon, aby zająć się swoimi kocimi sprawami. 
OOM Killer To kolejna sytuacja, która może wydarzyć się w kontenerze, gdy skończy się pamięć.Jeśli 
program wydostanie się poza kontener, otrzymamy OutOfMemory Killer (OOM Killer) - jest to proces, który kończy działanie aplikacji, aby uchronić jądro przed awarią. Poświęca aplikację, aby utrzymać działanie kontenera. To nie fakt, że kontener spadnie, ale aplikacja, która w nim działa, na pewno spadnie. Dzieje się tak, jeśli pozostawisz niekontrolowane zużycie pamięci przez aplikację Java. Znowu o kotach. Jeśli w sobotę zdecydowałeś się pospać dłużej i zapomniałeś dać kotu jedzenie, to OOM Killerkwiaty są gwarantowane, doniczki nie mogą zostać uszkodzone, ale kwiaty będą musiały zostać przesadzone. 
Jaka jest różnica między błędem OOM a zabójcą OOM? Możesz przetworzyć OOM Error i wykonać pewne czynności (na przykład: przeskalować aplikację), a OOM Killer po prostu zabije cały proces. OOM Killer jest podobny do kill-9 (kill minus dziewięć) - polecenia, które zabija proces w Linuksie . 
Rzecz w tym, że najpopularniejszą implementacją kontenera jest kontener Docker , który bazuje na Linuksie , nawet jeśli uruchomimy go pod Windowsem , jądro i tak będzie z Linuksa . W Linuksie interesuje nas jedno pojęcie: CGroups (angielska grupa kontrolna) - mechanizm jądra Linuksa, który ogranicza i izoluje zasoby obliczeniowe (procesor, sieć, zasoby pamięci, zasoby we/wy) dla grup procesów. Mówiąc najprościej, mechanizm ten pozwala na zarządzanie zasobami znajdującymi się w kontenerze, w naszym przypadku pamięcią. Jak Java ma się do tego? To dzięki mechanizmowi CGroups Java może zatrzasnąć się w pamięci kontenera. Ale to wszystko zależy od wersji Java. Na przykład Java 7 nie wie, jak używać CGroups i nie są jej znane limity kontenerów. Domyślnie maksymalny rozmiar sterty = ¼ pamięci fizycznej. Jeśli aplikacja przekroczy limity kontenerów to nastąpi OOM Killer , a jeśli limity kontenerów nie zostaną ustawione to aplikacja będzie pobierać pamięć od innych aplikacji na serwerze (lepiej ustawić limity, inaczej wszyscy stracą) . Możesz oczywiście użyć ustawień sterty lub użyć specjalnych „obrazów”, które rozwiązują ten problem, ale najłatwiejszym sposobem jest użycie poprawnej wersji Java. Poprawne wersje zaczynają się od Java 8 x131 (przeniesione z Java 9), zaczynają rozumieć CGroups . A w Javie 10 pojawiła się obsługa kontenerów: UseContainerSupport , później ta funkcja została przeniesiona na Javę 8 x 191 . Możesz też po prostu użyć Java: 11+ . Co można stwierdzić: Podczas korzystania z pamięci kontenera może zostać wyświetlony komunikat OutOfMemoryError (błąd OOM) lub OutOfMemoryKiller (OOM Killer). W pierwszym przypadku aplikacja nie ulegnie natychmiastowej awarii, błąd OOM można wychwycić, przetworzyć i podjąć kontrolowane działania. Na przykład skaluj aplikację. Jeśli wystąpi OOM Killer, aplikacja natychmiast się zawiesi i nie będzie możliwości jej zapisania. A najgorsze jest to, że na zewnątrz sam pojemnik będzie w porządku, to znaczy możesz nawet nie podejrzewać, że coś tam spadło. Mechanizmy systemu Linux służą do interakcji z kontenerem i pamięcią Java. Ale nie każda Java je implementuje. Aby uniknąć problemów z Javą 8, musisz użyć wersji zaczynającej się od 131 lub jeszcze lepiej od 191. Lub użyj Java: 11+. Dla praktyki: OutOfMemoryError: złap go, jeśli potrafisz
GO TO FULL VERSION