GNU/Linux OOM(메모리 부족) 정지 - 솔루션 아이디어

GNU/Linux OOM(메모리 부족) 정지 - 솔루션 아이디어

설명하다

스왑 및 2GB RAM이 있는 구형 시스템을 사용할 때 종종 정지 현상이 발생합니다.

여기에 있는 모든 질문과 답변은 주로 다음 사항에 중점을 두고 있습니다.

  • sysctl을 사용하여 조정 vm.min_free_kbytes하고vm.swappiness
  • 다른 제안 솔루션은 oom_score를 조정하고 OOM이 작동하도록 기도합니다.
  • zram 설정(스왑 압축)
  • 다양한 쉘 스크립트[1]종류[2]
  • 더 많은 메모리 등을 구입하는 것이 "권장"되기도 합니다.

나는 이러한 솔루션이 원인이 아닌 증상만을 해결한다는 것을 발견했습니다. 나는 독서를 통해 배웠다커널 문서OOM이 작동하더라도 현재는 두 가지 "모드"로 작동합니다.

  • 대부분의 메모리 소비 프로세스를 종료합니다(보통).
  • 또는 실제로 메모리 할당을 시도한 마지막 프로세스인 메모리 "범인"을 종료합니다.

두 가지 솔루션 모두 실제로 만족스럽지 않습니다.내가 내린 결론은 내가아니요OOM 실행을 통해 무작위 또는 마지막 프로세스를 종료하고 싶지만 시스템은 계속 실행하고 싶습니다. 무엇을 죽일지 스스로 결정하고 싶지만 프로세스의 oom_score를 조정하지는 않습니다.

질문

내가 알고 싶은/하고 싶은 것은:

  1. Never 커널(예: 4.0+)에서 상황이 변경/개선되었습니까?
  2. Ubuntu에서 변경된 사항이 있습니까(사용자 정의 패치? 12.04+)
  3. 이 두 가지 문제에 관계없이 저는 제안을 환영합니다.위 Q&A에는 언급되지 않았습니다..
  4. 위의 세 가지 문제를 제쳐두십시오. 다음과 같이 수정된 자체 /bin/login바이너리를 컴파일하는 것을 고려 중입니다.

    • 구성 가능한 메모리 양(예: 8MB)을 할당합니다.
    • 구성 가능한 사용자 공간 TUI(예: htop)를 복사/포크합니다(참조이것)
    • 상위 프로세스는 SIGTSTP를 전송하여 하위 프로세스를 일시 중지 상태로 만들고(CPU를 소비하지 않도록) 하위 프로세스의 fd를 닫을 수도 있습니다.
    • 부모는 사용자가 적절하게 인증된 경우에만 SIGTCONT를 자식에게 보냅니다. 보안상의 이유로 닫혀 있는 경우 하위 파일을 복원하는 것도 가능할 수 있습니다.
    • 이 로그인 긴급 바이너리는 upstart/systemd 또는 모든 init 바이너리에 의해 실행되며 필요한 프로세스가 종료될 수 있도록 높은 권한으로 실행될 수도 있습니다.

5. 이 접근 방식은 합리적으로 보입니까, 아니면 너무 지나친 것 같습니까? 한눈에 확연히 드러나는 보안 허점이 있나요?

관련 정보