설명하다
스왑 및 2GB RAM이 있는 구형 시스템을 사용할 때 종종 정지 현상이 발생합니다.
- 여기, Linux에서 메모리 부족 OOM 정지를 방지하는 가장 좋은 방법은 무엇입니까
- 여기, 메모리가 거의 가득 차면 컴퓨터가 정지됩니다. 디스크 캐시 문제일 수 있습니다.
- 그리고 여기, 메모리가 부족하면 시스템이 중단됩니다.
- 일반적으로 오랫동안 알려져 있었던 것 같은 버그
여기에 있는 모든 질문과 답변은 주로 다음 사항에 중점을 두고 있습니다.
- sysctl을 사용하여 조정
vm.min_free_kbytes
하고vm.swappiness
- 다른 제안 솔루션은 oom_score를 조정하고 OOM이 작동하도록 기도합니다.
- zram 설정(스왑 압축)
- 다양한 쉘 스크립트[1]종류[2]
- 더 많은 메모리 등을 구입하는 것이 "권장"되기도 합니다.
나는 이러한 솔루션이 원인이 아닌 증상만을 해결한다는 것을 발견했습니다. 나는 독서를 통해 배웠다커널 문서OOM이 작동하더라도 현재는 두 가지 "모드"로 작동합니다.
- 대부분의 메모리 소비 프로세스를 종료합니다(보통).
- 또는 실제로 메모리 할당을 시도한 마지막 프로세스인 메모리 "범인"을 종료합니다.
두 가지 솔루션 모두 실제로 만족스럽지 않습니다.내가 내린 결론은 내가아니요OOM 실행을 통해 무작위 또는 마지막 프로세스를 종료하고 싶지만 시스템은 계속 실행하고 싶습니다. 무엇을 죽일지 스스로 결정하고 싶지만 프로세스의 oom_score를 조정하지는 않습니다.
질문
내가 알고 싶은/하고 싶은 것은:
- Never 커널(예: 4.0+)에서 상황이 변경/개선되었습니까?
- Ubuntu에서 변경된 사항이 있습니까(사용자 정의 패치? 12.04+)
- 이 두 가지 문제에 관계없이 저는 제안을 환영합니다.위 Q&A에는 언급되지 않았습니다..
위의 세 가지 문제를 제쳐두십시오. 다음과 같이 수정된 자체
/bin/login
바이너리를 컴파일하는 것을 고려 중입니다.- 구성 가능한 메모리 양(예: 8MB)을 할당합니다.
- 구성 가능한 사용자 공간 TUI(예: htop)를 복사/포크합니다(참조이것)
- 상위 프로세스는 SIGTSTP를 전송하여 하위 프로세스를 일시 중지 상태로 만들고(CPU를 소비하지 않도록) 하위 프로세스의 fd를 닫을 수도 있습니다.
- 부모는 사용자가 적절하게 인증된 경우에만 SIGTCONT를 자식에게 보냅니다. 보안상의 이유로 닫혀 있는 경우 하위 파일을 복원하는 것도 가능할 수 있습니다.
- 이 로그인 긴급 바이너리는 upstart/systemd 또는 모든 init 바이너리에 의해 실행되며 필요한 프로세스가 종료될 수 있도록 높은 권한으로 실행될 수도 있습니다.
5. 이 접근 방식은 합리적으로 보입니까, 아니면 너무 지나친 것 같습니까? 한눈에 확연히 드러나는 보안 허점이 있나요?