OOM-killer가 때때로 리소스 호그를 죽이지 못하는 이유는 무엇입니까?

OOM-killer가 때때로 리소스 호그를 죽이지 못하는 이유는 무엇입니까?

쉘에 입력하면 메모리가 부족해질 때까지 영원히 쓰려고 하기 때문에 x=`yes`결국에는 오류가 발생합니다 . 커널의 OOM-killer가 할당할 바이트가 더 이상 없으며 즉시 종료되어야 한다는 메시지를 받았습니다 .cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated)yesxcannot allocate <memory>xrealloc

하지만 리소스가 부족하여 존재하지 않는 그래픽 메모리를 더 할당해 달라고 요청하면 game_engine대신 RAM과 CPU에 요청된 메모리를 할당하게 됩니다.

game_engine커널의 OOM-killer가 에서처럼 많은 양의 메모리를 할당하려는 시도를 포착하지 못하는 이유는 무엇입니까 x=`yes`?

즉, 실행 중이고 game_engine사용자가 memory-hog 이후 새 프로세스를 생성하지 않은 경우 OOM-killer가 시스템을 종료하지 않고도 내 시스템을 응답하지 않고 복구할 수 없는 상태로 만드는 데 항상 성공하는 game_engine이유는 무엇입니까 ?game_engine


나는 게임 엔진을 예로 들었습니다. 왜냐하면 게임 엔진은 나의 불쌍한 작은 통합 카드에 엄청난 양의 메모리를 할당하는 경향이 있기 때문입니다. 그러나 이것은 자원 집약적인 많은 X 프로세스에서 발생하는 것 같습니다.

OOM-killer가 효과가 없거나 프로세스의 메모리를 취소할 수 없는 경우가 있습니까?

답변1

실제로 OOM 킬러를 위한 최선의 솔루션은 OOM 킬러를 갖지 않는 것입니다. 오버커밋된 메모리를 사용하지 않도록 시스템을 구성하고 이에 의존하는 애플리케이션과 라이브러리의 사용을 거부하세요. 무한 디스크 시대에 무한 스왑을 제공하면 어떨까요? 메모리를 사용하지 않는 한 스왑을 커밋할 필요가 없습니다. 그렇죠?

귀하의 질문에 대한 대답은 OOM 킬러가 귀하가 생각하는 대로 작동하지 않는다는 것일 수 있습니다. OOM 킬러는 경험적 방법을 사용하여 종료할 프로세스를 선택하며, 규칙이 항상 마지막 요청자가 죽는다는 의미는 아닙니다. 참조.OOM 킬러 길들이기. 따라서 OOM 킬러가 "비효율적"이라는 문제가 아니라 그 중 하나가 사용자가 선호하는 것과 다른 선택을 하는 것입니다.

관련 정보