OOM 킬러를 더 일찍 개입시킬 수 있습니까?

34

개발 시스템을 최대한 신뢰하도록 조정하려고합니다. GUI 사용의 경우 대부분 더 이상 사용할 수없는 방식으로 시스템이 응답하지 않기 때문에 스왑을 비활성화했습니다. 그럼에도 불구하고 공격적인 어플리 케이 션이 메모리를 소모하면 일부 메커니즘은 속도 비용을 최대한 활용하는 메커니즘을 시작하는 것처럼 보입니다. 하드 드라이브 교체 작업은 없지만 시스템이 응답하지 않습니다. 따라서 시스템이 메모리 확보에 특별한 노력을 기울이기 전에 OOM 킬러가 시작되도록하고 싶습니다. 예를 들어 100MB 미만의 사용 가능한 실제 메모리가있는 경우 작동하도록 OOM 킬러를 구성 할 수 있습니까?

linux-kernel memory-management

— 드로 너스
소스

2

여기서 진짜 문제는 램이 충분하지 않다는 것입니다. 램이 없으면 스왑을 사용하지 않습니다. 스왑을 해제하면 ... 램이 부족하여 페이지를 넘길 곳이 없습니다. 추악한 일이 발생합니다. 귀하의 시스템이 잘못 설정되어있는 것으로 보이며,이를 수정해도 문제가 해결되지 않습니다.

— Journeyman Geek

8

동의하지 않습니다. 개발 및 '전력 사용'에는 종종 실험적 사용이 포함됩니다. 예를 들어, 명령 행 이미지 처리 도구를 사용하는 경우 이미지 크기와 관련하여 작동하는 메모리 양에 대한 스펙이 없습니다. 그래서 나는 단지 그것을 실행합니다. 그리고 나는 그것이 전체 기계를 쓸모 없게 만들 것으로 기대하지 않습니다. 단일 실험의 경우 ulimit를 사용하여 보안을 유지할 수는 있지만 때로는 많은 작업을 수행하는 전체 시스템 작업의 경우 하나의 프로세스를 포함하는 것이 그렇게 유용하지는 않지만 전체 시스템의 '생명 보험'은 명확합니다.

— dronus

1

스왑을 사용할 때 시스템이 그리드에 정지한다는 사실이 의심됩니다. 컴퓨터에서 스왑을 사용하면 메모리가 부족합니다. 스왑 속도가 느려 디스크 액세스 속도가 느려집니다. ???로 인해 디스크 액세스가 느립니다. 문제가 끝이났습니다. 당신이 숫양이 적다는 것이 아닙니다. 그것은 다른 방법으로 인해 그것을 완화시키는 한 가지 방법을 사용할 수 없다는 것입니다.

— Journeyman Geek

7

@JourneymanGeek, 왼쪽 필드에 있습니다. 디스크는 램과 비교하여 속도가 느리기 때문에 과도한 스와핑은 항상 시스템을 정지시킵니다. 물론 그는 많은 메모리를 사용하는 프로그램을 실행하려고했기 때문에 메모리가 부족합니다. 문제는 메모리가 부족할 때 어떻게해야합니까? 디스크 캐시에 남은 메모리가 없어서 돼지를 죽이거나 속도를 늦 춥니 다.

— psusi

2

@TomWijsman, Disk IO는 메모리 IO보다 수십 배 느리므로 디스크 스왑을 사용하면 항상 속도가 크게 느려집니다. 때로는 (특히 램이 비싸고 대부분의 사람들이 많이 가지고 있지 않은 옛날에는) 당신이 전혀 시도하지 않은 일을하는 것이 바람직하지 않습니다. 요즘 디스크가 SO 훨씬 느린 램보다, 그리고 램은 대부분의 사람들이 그래서 그들은 실수로 더 사용은 그들이 가지고보다 램 뭔가를 실행 드문 경우에, 충분한 지 싼만큼, 그것은 걸릴 1000보다 포기하는 것이 낫다 그것을 할 시간이 오래.

— psusi

36

나는 또한 그 문제로 어려움을 겪었다. 나는 시스템이 무엇이든 관계없이 반응을 유지하기를 원하며 몇 분 동안 프로세스를 잃는 것을 선호합니다. 커널 oom killer를 사용하여 이것을 달성 할 수있는 방법이없는 것 같습니다.

그러나 사용자 공간에서는 원하는대로 할 수 있습니다. 따라서 가용 RAM이 10 % 이하로 떨어지면 RSS로 가장 큰 프로세스를 중단시키는 Early OOM Daemon ( https://github.com/rfjakob/earlyoom )을 작성했습니다 .

earlyoom이 없으면 http://www.unrealengine.com/html5/ 를 몇 번 시작하여 내 컴퓨터 (8GB RAM)를 쉽게 잠글 수 있습니다. 이제 유죄 브라우저 탭은 문제가 해결되기 전에 종료됩니다.

— 야콥
소스

3

이 가려움을 긁어 주셔서 감사합니다! 일찍부터 사랑해.

— 토마스 페리스 니콜라이 센

1

안드로이드가 오랫동안 똑같이 작동한다는 것을 알았습니다. 그것이 당신과 같은 사용자 지정 코드를 사용하고 있는지 확실하지 않습니다.

— dronus

1

earlyoom지금 테스트 중이며 첫 번째 트리거 테스트에서 잘 수행됩니다. 왜 커널 구성이나 시스템 도구로 구현할 수 없는지 궁금합니다.

— dronus

12

커널의 기본 정책은 사용 가능한 실제 메모리가있는 한 응용 프로그램이 가상 메모리 할당을 유지하도록 허용하는 것입니다. 실제 메모리는 응용 프로그램이 할당 한 가상 메모리에 닿을 때까지 실제로 사용되지 않으므로 응용 프로그램이 시스템보다 많은 메모리를 할당 한 다음 나중에 메모리를 시작하여 커널에 메모리가 부족하게되고 메모리 (OOM) 킬러 그러나 호깅 프로세스가 종료되기 전에 디스크 캐시가 비워져 캐시가 다시 채워질 때까지 시스템의 응답 속도가 느려집니다.

값을 2로 쓰면 메모리 초과 커밋을 허용하지 않도록 기본 정책을 변경할 수 있습니다 /proc/sys/vm/overcommit_memory. 기본값 /proc/sys/vm/overcommit_ratio은 50이므로 커널은 응용 프로그램이 ram + swap의 50 % 이상을 할당 할 수 없습니다. 스왑이없는 경우 커널은 응용 프로그램이 램의 50 % 이상을 할당 할 수 없으며 다른 50 %는 캐시에 사용할 수 있습니다. 이는 약간 과도 할 수 있으므로이 값을 85 % 정도로 늘리면 애플리케이션이 램의 최대 85 %를 할당하여 캐시에 15 %를 남겨 둘 수 있습니다.

— 가우
소스

1

이론적 배경이없는 기본값 에서이 값을 변경하면보다 안정적인 시스템에 도달 할 수 없으므로 적절한 통계를 사용하여 해당 변경 사항을 정당화 할 수 있습니다. 변경할 수 있다고해서 꼭 그래야하는 것은 아닙니다. 메모리가 부족한 상태에서 지속적으로 메모리를 더 많이 사용하고 더 많은 메모리를 구입해야한다고해서 설정을 조정하고 임의의 응용 프로그램을 종료해야한다는 의미는 아닙니다. 당신의 일상적인 일을 방해하거나 부패를 초래하는 것은 실제로 갈 길은 아닙니다 ...

— Tamara Wijsman

3

@TomWijsman,이 질문은 그가 메모리 부족 상태에 있지 않다는 것을 분명히한다. 그는 때때로 예기치 않게 많은 양의 메모리를 사용하는 명령을 실행합니다. 메모리가 부족할 때 더 많은 메모리를 구매하는 것이 유일한 해결책은 아닙니다. 다른 잠재적 솔루션으로는 보유한 메모리를 사용하는 더 좋은 방법을 찾거나 필요한만큼의 메모리를 사용하지 않는 것 등이 있습니다. 문제는 외자가 더 많은 램을 사는 것보다 후자가 더 수용 가능하다는 것을 분명히합니다.

— psusi

질문의 어느 줄이 이것을 명확하게합니까? 에 반대의 내용이 I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.있습니다. 그는 명령을 실행한다고 가정하면서 GUI를 언급했습니다. 더 많은 메모리를 구매하는 것이 첫 번째 솔루션이며, 더 적은 메모리를 사용하는 것이 두 번째 솔루션입니다. 안정적인 기본값으로 조정하여 시스템을 불안정하게 만드는 것이 마지막 솔루션입니다. 질문에 문자 그대로 답할 필요가 없으므로 의견에 우리 둘 다 귀찮게 해야하는 문제가 무엇인지 알 수 없습니다. Rant는 도움이되지 않습니다 ...

— Tamara Wijsman

4

이 답변은 정말 멋지다. 불행히도, '커밋'은 가상 메모리 수요를 의미하며, 이는 애플리케이션 프로그래머가 추정 한 것입니다. 예를 들어, (스왑이없는) 데스크톱이 실행중인 경우 약 400MB의 2000MB 실제 메모리가 사용되지만 1600mb는 '커밋 /proc/meminfo' Committed_AS상태 로 ' 커밋'되었습니다 . 일부 응용 프로그램을 실행하면이 값이 실제 메모리를 쉽게 초과하므로 이로 인해 실행 가능한 제한을 설정하기가 어렵습니다.

— dronus

3

시도하기 전에 작업을 저장하십시오! : PI는 모든 것 (bash, window manager 등)에서 즉시 실패했습니다.

— jozxyqk 5

8

나를 위해 vm.admin_reserve_kbytes = 262144를 설정하면 정확히이 작업을 수행합니다. 시스템이 완전히 응답하지 않기 전에 OOM 킬러가 개입합니다.

— 마이클 비고 프 스키
소스

1

나는 아이디어를 좋아하지만 256MiB의 실제 메모리를 사용하지 않았다는 것을 의미합니까?

— Jérôme Pouiller 2016 년

1

캐시에는 256MiB가 사용됩니다. 캐시는 정말 중요합니다. 단지 더 빨리 실행되는 것이 아니라 캐시를위한 메모리가 충분하지 않으면 시스템이 전혀 작동하지 않습니다. 실행중인 모든 프로그램의 코드는 mmap되어 디스크에서 다시 읽을 수 있기 때문에 메모리에서 언로드 될 수 있습니다. 캐시가 없으면 모든 작업 스위치에 디스크 읽기가 필요하고 시스템이 완전히 응답하지 않게됩니다.

— Michael Vigovsky 2014 년

4

다른 답변에는 좋은 자동 솔루션이 있지만 문제 SysRq가 발생했을 때 키를 활성화하는 것이 도움이 될 수 있습니다 . 이 SysRq키를 사용하면 커널에 수동으로 메시지를 SysRQ + REISUB보내고 사용자 공간이 완전히 정지 된 경우에도 안전한 재부팅 ( )을 수행 할 수 있습니다 .

커널이 요청을 수신하도록 허용하려면 kernel.sysrq = 1비트 마스크와 함께 사용할 가능성이있는 기능 만 설정 하거나 활성화 하십시오 ( 여기에 설명되어 있음 ). 예를 들어 kernel.sysrq = 244위의 안전한 재부팅에 필요한 모든 콤보와을 사용하여 OOM 킬러를 수동으로 호출 할 수 SysRq + F있습니다.

— 티 무슈 티
소스

-2

메모리가 부족하고 OOM 킬러로 인해 안정성에 도달하지 못합니다.

옷장에 파티를 조직하고 작은 재생 목록에 "내 옷장 정리" 를하는 것은 잘못 입니다.

OOM 킬러를 더 일찍 개입시킬 수 있습니까?

이렇게하면 살해 대상을 제어 할 수 없으므로 의도하지 않은 결과가 발생합니다.

개발 시스템을 최대한 신뢰하도록 조정하려고합니다.

최대의 안정성에는 시스템 테스트 및 이러한 테스트를 기반으로 시스템을 개선 하는 것이 포함됩니다 .

임의의 것을 조정 하면 어디서나 얻을 수 없습니다 ...

GUI 사용의 경우 대부분 더 이상 사용할 수없는 방식으로 시스템이 응답하지 않기 때문에 스왑을 비활성화했습니다. 그럼에도 불구하고 공격적인 어플리 케이 션이 메모리를 소모하면 일부 메커니즘은 속도 비용을 최대한 활용하는 메커니즘을 시작하는 것처럼 보입니다.

메모리 부족 상태로 인해 스왑을 해제하는 동작이 향상되지 않습니다 , 그것은 반대를 않습니다 .

이 상황에서 안정성을 높이려면 시스템의 응답 성이 향상되고 사용자의 의도없이 임의의 프로세스가 종료되지 않도록 메모리를 추가하십시오. 메모리가 부족한 상태와 이와 같은 메커니즘에 의존해서는 안되며, 특히 개발 환경에서는 그렇지 않습니다.

하드 드라이브 교체 작업은 없지만 시스템이 응답하지 않습니다.

메모리가 부족하면 스왑 여부에 관계없이 실제로 응답하지 않습니다.

따라서 시스템이 메모리 확보에 특별한 노력을 기울이기 전에 OOM 킬러가 시작되도록하고 싶습니다.

위에서 설명한 것처럼 선보다 해를 끼칠 특별한 노력. 대신, 당신은 당신이 필요로하지 않는 프로세스를 죽일 수는 있지만, 그렇게 할 수 없기 때문에 OOM이 필요한 프로세스를 죽일 것입니다.

예를 들어 100MB 미만의 사용 가능한 실제 메모리가있는 경우 작동하도록 OOM 킬러를 구성 할 수 있습니까?

아마도 요즘 실제로 비용이 많이 들지 않는 여분의 메모리를 구입하면 더 높은 투자 수익을 얻을 수 있습니다. 메모리가 부족한 상태에서 계속 작업한다면 장기적으로 발에 걸리게 될 것입니다. OOM은 집행관과 같으며 도움이되지 않으며 OS를 지원합니다 ...

— 타마라 위즈 먼
소스

7

물론 스왑을 비활성화하면 디스크를 스 래싱하는 대신 OOM이 메모리 호그를 시작하고 종료하기 때문에 동작이 향상됩니다. 램이 부족한 것은 문제가되지 않습니다 (더 많은 것을 추가한다는 것은 더 열심히 뛰기 위해 노력해야한다는 것을 의미합니다). 문제는 부족할 때해야 할 일입니다. OOM에서 돼지를 죽이고 메모리 부족 상태를 완화하려고합니다.

— psusi

7

더 많은 메모리를 사용하려고하는 응용 프로그램을 종료하면 전체 시스템을 무릎에 싣는 것이 좋습니다. 완벽한 세상에서 당신은 무제한의 메모리를 가지게 될 것입니다. 그러나 실제로는, 때때로 우연히 닳아서 시스템이 멈추는 것보다 "메모리가 충분하지 않습니다"라고 말하는 것입니다.

— psusi

5

여분의 메모리를 구입하면 구입 한 양에 따라 일부 문제가 해결 될 수 있습니다. 그러나 순서에 따라 예기치 않은 사용법이있을 수 있다는 사실은 변하지 않습니다. 따라서 응용 프로그램이 실패하기를 원하지만 그러한 조건에서는 시스템이 아닙니다. 몇 가지 예 : 압축 된 이미지로 가득 찬 폴더를 처리합니다. 대부분은 "일반"크기이지만 일부는 실제로 크기가 큽니다. 작은 실수는 1GB / s의 메모리 런 어웨이로 데드 루프를 만들 수 있습니다. 실수로 텍스트 편집기에서 비디오 파일을 엽니 다. 보통 이것은 OOM이

— 시작될

6

@TomWijsman은 입력 데이터에 따라 평균적으로 선형으로 동작하지만 최악의 경우 지수로 작동하는 알고리즘이 있기 때문에 거의 죽은 루프가 있습니다. 마우스가 흔들리고 딸깍 소리가 나고 키보드 입력에 1 분의 대기 시간이 표시되면 킬 신호를 보낼 수 없습니다. 나는 보통 텍스트 모드 터미널로 변경하고 kill맹목적으로 입력 하기 위해 로그인이 진행될 때까지 몇 분 기다립니다 .

— dronus

7

죽은 응용 프로그램을 죽이는 데 아무런 문제가 없습니다. 2GB 물리적 + 2GB 스왑이있는 시스템을 고려하십시오. 실제 메모리를 빨리 소모하는 응용 프로그램은 쉽게 스왑을 먹을 수 있습니다. 몇 분에서 몇 시간 동안 시스템이 응답하지 않게 된 후에 나중에 죽을 것입니다. 그렇다면 GUI 작업이 벗겨지기 전에 왜 빨리 죽이지 않습니까? 많은 프로세스가 10MB로 모든 작업을 수행하고 일부는 1GB를 사용하며 일부는 10GB가 필요합니다.

— dronus