.png)
저는 AWS에서 16개의 CPU와 32GB의 메모리를 갖춘 CentOS 7.5 인스턴스를 사용하고 있습니다. 다음 명령을 실행했을 때 전체 시스템이 응답하지 않고 더 이상 명령을 실행할 수 없거나 새 SSH 세션을 설정할 수도 없다는 사실을 발견했습니다(그러나 여전히 ping은 가능함). 그리고 OOM 킬러가 전혀 작동하지 않는 것을 볼 수 있습니다. 전체 시스템이 영원히 정지된 것처럼 보입니다.
stress --vm 1 --vm-bytes 29800M --vm-hang 0
그러나 더 많은 메모리(50MB)를 소비하면 stress --vm 1 --vm-bytes 29850M --vm-hang 0OOM Kill이 성공적으로 트리거됩니다(에서 볼 수 있습니다 dmesg). stress29800MB 미만의 메모리를 소비하는 명령(예: )을 실행하면 stress --vm 1 --vm-bytes 29700M --vm-hang 0시스템이 응답하고(OOM 종료 없음) 평소대로 모든 명령을 실행할 수 있습니다.
따라서 이 경우에는 29800MB"마법의 숫자"인 것 같습니다. stress실제보다 더 많은 메모리를 사용하도록 명령을 실행하면 OOM에 의해 명령이 종료되고, stress실제보다 적은 메모리를 사용하도록 명령을 실행하면, 그러면 모든 것이 괜찮습니다. 29800MB의 메모리만 사용하여 명령을 실행하면 stress전체 시스템이 응답하지 않게 됩니다. 또한 사양이 다른 Linux 호스트에서도 동일한 동작을 관찰했습니다. 예를 들어 CPU 72개와 RAM 144GB를 갖춘 CentOS 7.5 인스턴스에서 "매직 넘버"는 "137600MB"입니다.
내 질문은 메모리의 "마법의 숫자"를 사용할 때 왜 OOM Kill이 트리거되지 않습니까?
답변1
아, 이 주제가 논의되었습니다.
바라보다:
Linux 커널은 낮은 메모리 부족을 정상적으로 처리할 수 없습니다.
방 안의 코끼리에 대해 이야기해 봅시다. Linux 커널은 낮은 메모리 부족을 적절하게 처리할 수 없습니다.
해결책? 등의 다양한 데몬아침(Fedora 32에서는 기본적으로 설치되고 활성화됩니다.) 이것은 제가 가장 좋아하는 것입니다. 아직 더 많은 것이 있습니다:
- 누오항- 솔루션 섹션도 읽어보세요.
- 옴
- 메모리 부족 모니터
- psi 모니터
답변2
문제의 근본 원인은 모든 프로세스를 실행하려고 시도하는 동안 아무런 진전이 없을 때만 OOM Killer가 활성화된다는 것입니다. "앞으로 진행"은 연속적으로 사용 가능한 일부 메모리로 간주됩니다. 여기서 "연속"은 전체 가상 메모리 페이지 테이블 구조를 한 번 스캔한 후 최소 4KB 이상의 RAM이 추가된 것입니다.
최악의 경우 동작은 시스템이 중단된 것처럼 보일 정도로 오랫동안 구조를 지속적으로 검색해야 하는 것입니다. 왜냐하면 이 프로세스에는 시간 제한이 없고 메모리 하위 시스템이 앞으로 이동할 수 있는 한 매우 느리더라도 계속 진행하려고 시도하기 때문입니다. 전체 메모리를 검색하는 데 최대 0.5초가 걸릴 수 있으며 최악의 경우 앞으로 진행하면 4KB의 여유 메모리가 생성됩니다. 시스템이 실제로 디스플레이를 다시 렌더링하는 데 20MB가 필요한 경우 성공하려면 약 2500번의 메모리 스캔이 필요하며 30분 이상이 소요됩니다. 분명히 화면을 새로 고치는 데 30분이 걸리는 시스템은 커널이 진행 상황에 만족하더라도 시스템이 사용자에게 완전히 정지되는 것과 같습니다.
가장 좋은 옵션은 메모리 하위 시스템의 최대 대기 시간을 지정하고 대기 시간이 너무 높을 때 OOM Killer가 자동으로 활성화되도록 하는 것입니다(예: 메모리 관리 하위 시스템은 초당 최소 100MB의 여유 공간을 제공할 수 있어야 합니다. 또는 시스템 상태가 RAM 부족으로 간주되어야 합니다.) 또는 기타 유사한 솔루션의 문제점 earlyoom은 높은 피크 부하에서 최악의 동작을 방지하기 위해 이러한 솔루션에는 매우 넓은 안전 여유가 필요하므로 안전 여유를 위해 RAM을 낭비하게 된다는 것입니다.