컨테이너와 Docker 에 대해 읽었 지만 Java가 컨테이너에 어떻게 고정되었는지 이해하지 못하는 사람들을 위한 것입니다. 먼저 Java 메모리 에 대한 기억을 새롭게 해보자 . 메모리는 서버의 RAM(Random Access Memory)을 사용하는 스택(Stack)과 힙(Heap)으로 구성된다는 점을 상기시켜드리고, 메모리에 관해 더 자세히 설명하면 RAM을 의미하게 됩니다. 이제 컨테이너의 단면을 살펴보겠습니다. 아니요, 물론 아닙니다. 우리는 엉덩이와 허벅지에는 관심이 없습니다. 컨테이너의 메모리 구조를 살펴보겠습니다. 이는 세 부분으로 나눌 수 있습니다. • 힙 메모리 – 힙 자체. • 오프 힙(Off Heap)은 힙에 없는 모든 것입니다. • OS 오버헤드는 컨테이너 내부 프로세스를 구현하기 위한 메모리 오버헤드입니다. 예를 들어, 컨테이너에 1Gb를 할당했는데 그림에서는 컨테이너 제한 이 됩니다 . 해당 경계는 파란색 직사각형으로 표시됩니다. 컨테이너 내 Java 메모리로 80%, 즉 0.8Gb를 할당했고, OS Overhead가 리소스 (오버헤드) 의 일부를 차지했기 때문에 Heap은 컨테이너의 약 80%, 즉 0.8Gb 이상을 차지했습니다. 프로세스 유지를 위해. 힙에 연결되지 않은 모든 항목을 위해 컨테이너의 약 20%가 남아 있습니다( 오프 힙 ). 그림의 사용 영역은 애플리케이션 실행에 사용되는 메모리 영역을 나타냅니다. 이제 컨테이너의 메모리가 부족할 수 있는 상황에 대해 이야기해야 합니다. OutOfMemoryError 애플리케이션의 메모리 소비( 사용 영역 )가 힙 제한( Heap )에 도달하면 OutOfMemoryError(OOM 오류)가 발생합니다 . 이는 힙, 즉 애플리케이션에서 프로그래밍 방식으로 생성된 개체가 배치되는 메모리 영역에 공간이 충분하지 않다는 의미입니다. 아직 완전히 명확하지 않다면 고양이로 설명하겠습니다. OOM 에러 는 고양이가 발코니 문 앞에서 오랫동안 비명을 지르다가 이 문이 열리면 문가에 서서 어느 쪽으로도 가지 않고 고양이가 얼어붙었다는 말을 자주 하는 경우입니다. 시간에 맞춰 밀면 턱을 떨어뜨리고 고양이 장사를 하러 발코니로 갈 것입니다. OOM Killer 이는 메모리가 부족할 때 컨테이너에서 발생할 수 있는 또 다른 상황입니다. 프로그램이 컨테이너 외부로 나가면 OutOfMemory Killer(OOM Killer)가 발생합니다 . 이는 커널이 충돌하지 않도록 애플리케이션을 종료하는 프로세스입니다. 컨테이너를 계속 실행하기 위해 애플리케이션을 희생합니다. 컨테이너가 추락한다는 것은 사실이 아니지만 그 안에서 실행되는 애플리케이션은 확실히 추락할 것입니다. 이는 Java 애플리케이션의 메모리 소비를 제어하지 않은 상태로 두면 발생합니다. 다시 고양이에 대해. 토요일에 더 오래 자기로 결정하고 고양이에게 음식을 주는 것을 잊었다면 OOM Killer꽃은 보장되고 화분은 손상되지 않을 수 있지만 꽃을 다시 심어야 합니다. OOM 오류와 OOM Killer의 차이점은 무엇입니까? OOM 오류를 처리 하고 일부 작업(예: 응용 프로그램 확장)을 수행할 수 있으며 OOM Killer는 단순히 전체 프로세스를 종료합니다. OOM Killer는 Linux 에서 프로세스를 종료하는 명령인 kill-9 (kill 빼기 9) 와 유사합니다 . 문제는 가장 널리 사용되는 컨테이너 구현이 Linux 기반의 Docker 컨테이너 라는 것입니다. Windows 에서 실행하더라도 커널은 여전히 Linux 에서 실행됩니다 . Linux에서 우리는 한 가지 개념에 관심이 있습니다. CGroups(영어 제어 그룹) - 프로세스 그룹의 컴퓨팅 리소스(프로세서, 네트워크, 메모리 리소스, I/O 리소스)를 제한하고 격리하는 Linux 커널 메커니즘입니다. 간단히 말해서 이 메커니즘을 사용하면 컨테이너의 리소스(이 경우 메모리)를 관리할 수 있습니다. Java는 이것과 어떤 관련이 있습니까? Java가 컨테이너 메모리를 확보할 수 있는 것은 CGroups 메커니즘을 통해서입니다. 하지만 이는 모두 Java 버전에 따라 다릅니다. 예를 들어 Java 7은 CGroups 사용 방법을 모르고 컨테이너 제한도 알 수 없습니다. 기본적으로 최대 힙 크기는 물리적 메모리의 ¼입니다 . 응용 프로그램이 컨테이너 제한을 초과하면 OOM Killer가 발생하고 컨테이너 제한이 설정되지 않으면 응용 프로그램은 서버의 다른 응용 프로그램에서 메모리를 가져옵니다(제한을 설정하는 것이 더 좋으며 그렇지 않으면 모든 사람이 손실됩니다). . 물론 이 문제를 해결하기 위해 힙 설정을 사용 하거나 특수 "이미지"를 사용할 수 있지만 가장 쉬운 방법은 올바른 Java 버전을 사용하는 것입니다. 올바른 버전은 Java 8 x131 (Java 9에서 이식됨) 로 시작하며 CGroups를 이해하기 시작합니다 . 그리고 Java 10 에서는 컨테이너에 대한 지원이 나타납니다: UseContainerSupport . 나중에 이 기능은 Java 8 x 191 로 포팅되었습니다 . 아니면 그냥 Java: 11+ 를 사용해도 됩니다 . 결론은 다음과 같습니다. 컨테이너 메모리를 사용할 때 OutOfMemoryError(OOM 오류) 또는 OutOfMemoryKiller(OOM Killer)가 발생할 수 있습니다. 첫 번째 경우, 애플리케이션이 즉시 충돌하지 않고 OOM 오류를 포착하여 처리하고 제어된 조치를 취할 수 있습니다. 예를 들어 애플리케이션을 확장합니다. OOM Killer가 발생하면 응용 프로그램이 즉시 충돌하고 이를 저장할 수 있는 옵션이 남지 않습니다. 그리고 최악의 점은 겉으로는 용기 자체가 괜찮을 것입니다. 즉, 거기에 무언가가 떨어졌다는 사실조차 의심하지 못할 수도 있다는 것입니다. Linux 메커니즘은 컨테이너 및 Java 메모리와 상호 작용하는 데 사용됩니다. 그러나 모든 Java가 이를 구현하는 것은 아닙니다. Java 8의 문제를 방지하려면 131 또는 191부터 시작하는 버전을 사용해야 합니다. 또는 Java: 11+를 사용하세요. 연습용: OutOfMemoryError: 가능하면 잡아내세요.
아니요, 물론 아닙니다. 우리는 엉덩이와 허벅지에는 관심이 없습니다. 컨테이너의 메모리 구조를 살펴보겠습니다. 이는 세 부분으로 나눌 수 있습니다. • 힙 메모리 – 힙 자체. • 오프 힙(Off Heap)은 힙에 없는 모든 것입니다. • OS 오버헤드는 컨테이너 내부 프로세스를 구현하기 위한 메모리 오버헤드입니다. 예를 들어, 컨테이너에 1Gb를 할당했는데 그림에서는 컨테이너 제한
이 됩니다 . 해당 경계는 파란색 직사각형으로 표시됩니다. 컨테이너 내 Java 메모리로 80%, 즉 0.8Gb를 할당했고, OS Overhead가 리소스 (오버헤드) 의 일부를 차지했기 때문에 Heap은 컨테이너의 약 80%, 즉 0.8Gb 이상을 차지했습니다. 프로세스 유지를 위해. 힙에 연결되지 않은 모든 항목을 위해 컨테이너의 약 20%가 남아 있습니다( 오프 힙 ). 그림의 사용 영역은 애플리케이션 실행에 사용되는 메모리 영역을 나타냅니다. 이제 컨테이너의 메모리가 부족할 수 있는 상황에 대해 이야기해야 합니다. OutOfMemoryError 애플리케이션의 메모리 소비( 사용 영역 )가 힙 제한( Heap )에 도달하면 OutOfMemoryError(OOM 오류)가 발생합니다 . 이는 힙, 즉 애플리케이션에서 프로그래밍 방식으로 생성된 개체가 배치되는 메모리 영역에 공간이 충분하지 않다는 의미입니다. 아직 완전히 명확하지 않다면 고양이로 설명하겠습니다. OOM 에러 는 고양이가 발코니 문 앞에서 오랫동안 비명을 지르다가 이 문이 열리면 문가에 서서 어느 쪽으로도 가지 않고 고양이가 얼어붙었다는 말을 자주 하는 경우입니다. 시간에 맞춰 밀면 턱을 떨어뜨리고 고양이 장사를 하러 발코니로 갈 것입니다. OOM Killer 이는 메모리가 부족할 때 컨테이너에서 발생할 수 있는 또 다른 상황입니다. 프로그램이 컨테이너 외부로 나가면 OutOfMemory Killer(OOM Killer)가 발생합니다 . 이는 커널이 충돌하지 않도록 애플리케이션을 종료하는 프로세스입니다. 컨테이너를 계속 실행하기 위해 애플리케이션을 희생합니다. 컨테이너가 추락한다는 것은 사실이 아니지만 그 안에서 실행되는 애플리케이션은 확실히 추락할 것입니다. 이는 Java 애플리케이션의 메모리 소비를 제어하지 않은 상태로 두면 발생합니다. 다시 고양이에 대해. 토요일에 더 오래 자기로 결정하고 고양이에게 음식을 주는 것을 잊었다면 OOM Killer
꽃은 보장되고 화분은 손상되지 않을 수 있지만 꽃을 다시 심어야 합니다. 
OOM 오류와 OOM Killer의 차이점은 무엇입니까? OOM 오류를 처리 하고 일부 작업(예: 응용 프로그램 확장)을 수행할 수 있으며 OOM Killer는 단순히 전체 프로세스를 종료합니다. OOM Killer는 Linux 에서 프로세스를 종료하는 명령인 kill-9 (kill 빼기 9) 와 유사합니다 . 문제는 가장 널리 사용되는 컨테이너 구현이 Linux 기반의 Docker 컨테이너 라는 것입니다. Windows 에서 실행하더라도 커널은 여전히 Linux 에서 실행됩니다 . Linux에서 우리는 한 가지 개념에 관심이 있습니다. CGroups(영어 제어 그룹) - 프로세스 그룹의 컴퓨팅 리소스(프로세서, 네트워크, 메모리 리소스, I/O 리소스)를 제한하고 격리하는 Linux 커널 메커니즘입니다. 간단히 말해서 이 메커니즘을 사용하면 컨테이너의 리소스(이 경우 메모리)를 관리할 수 있습니다. Java는 이것과 어떤 관련이 있습니까? Java가 컨테이너 메모리를 확보할 수 있는 것은 CGroups 메커니즘을 통해서입니다. 하지만 이는 모두 Java 버전에 따라 다릅니다. 예를 들어 Java 7은 CGroups 사용 방법을 모르고 컨테이너 제한도 알 수 없습니다. 기본적으로 최대 힙 크기는 물리적 메모리의 ¼입니다 . 응용 프로그램이 컨테이너 제한을 초과하면 OOM Killer가 발생하고 컨테이너 제한이 설정되지 않으면 응용 프로그램은 서버의 다른 응용 프로그램에서 메모리를 가져옵니다(제한을 설정하는 것이 더 좋으며 그렇지 않으면 모든 사람이 손실됩니다). . 물론 이 문제를 해결하기 위해 힙 설정을 사용 하거나 특수 "이미지"를 사용할 수 있지만 가장 쉬운 방법은 올바른 Java 버전을 사용하는 것입니다. 올바른 버전은 Java 8 x131 (Java 9에서 이식됨) 로 시작하며 CGroups를 이해하기 시작합니다 . 그리고 Java 10 에서는 컨테이너에 대한 지원이 나타납니다: UseContainerSupport . 나중에 이 기능은 Java 8 x 191 로 포팅되었습니다 . 아니면 그냥 Java: 11+ 를 사용해도 됩니다 . 결론은 다음과 같습니다. 
컨테이너 메모리를 사용할 때 OutOfMemoryError(OOM 오류) 또는 OutOfMemoryKiller(OOM Killer)가 발생할 수 있습니다. 첫 번째 경우, 애플리케이션이 즉시 충돌하지 않고 OOM 오류를 포착하여 처리하고 제어된 조치를 취할 수 있습니다. 예를 들어 애플리케이션을 확장합니다. OOM Killer가 발생하면 응용 프로그램이 즉시 충돌하고 이를 저장할 수 있는 옵션이 남지 않습니다. 그리고 최악의 점은 겉으로는 용기 자체가 괜찮을 것입니다. 즉, 거기에 무언가가 떨어졌다는 사실조차 의심하지 못할 수도 있다는 것입니다. Linux 메커니즘은 컨테이너 및 Java 메모리와 상호 작용하는 데 사용됩니다. 그러나 모든 Java가 이를 구현하는 것은 아닙니다. Java 8의 문제를 방지하려면 131 또는 191부터 시작하는 버전을 사용해야 합니다. 또는 Java: 11+를 사용하세요. 연습용: OutOfMemoryError: 가능하면 잡아내세요.
GO TO FULL VERSION