답변:
나는 시스템이 실제로 "동결"되지 않았고 (커널이 정지되었다는 의미에서) 오히려 응답이없는 것이 틀림 없다. 인터랙티브 한 성능과 시스템 처리량이 급격히 떨어질 수밖에 없었습니다.
스왑을 해제 할 수 는 있지만 사용 가능한 디스크 캐시로 인한 성능 저하와 함께 성능 저하에서 OOM으로 죽인 프로세스 (및 발생하는 모든 재미)로 문제가 변경됩니다.
또는 프로세스 당 리소스 제한 (일반적으로 rlimit및 / 또는 라고도 함 ulimit)을 사용하여 단일 프로세스에서 엄청나게 많은 양의 메모리를 사용하여 스와핑을 유발할 가능성을 제거 할 수 있습니다. 시스템이 원하는 것보다 조금 더 많은 메모리를 원했기 때문에 불편한 순간.
대량의 메모리 사용을 유발할 수있는 작업을 수행 할 줄 알았다면, mlockall()쉘을 실행 한 다음 랩을 실행 한 랩퍼 프로그램을 작성할 수 있습니다. 그것은 메모리에 유지되며, CPU가 과도하게 사용되지 않고 문제가되는 것이기 때문에 "응답 성 코어를 유지하는"가장 가까운 것입니다.
개인적으로, 나는 "멍청한 일을하지 말라"는 자원 통제 방법에 가입한다. 당신이 루트를 가지고 있다면, 당신은 시스템 손상의 모든 종류를 할 수 있고, 일 때문에 아무것도 당신의 가능성이 결과를 모르는를 위험한 사업이다.
ulimit, 심지어 요즘 청년층이라면 요즘 cgroup에서도 잘 작동합니다. 중요하지 않은 환경에서 영향을 검증하지 않고 프로덕션에서 쿼리를 변경하는 경우 근본 원인이 문제입니다.
Tronic의 설명에서 위에서 언급했듯이 키보드 조합 SysRq- 을 사용하여 OOM-killer (메모리 킬러에서)를 직접 호출 할 수 있습니다 F.
SysRq키는 일반적 PrtSc으로 키보드의 키 내에 결합됩니다 .
OOM-killer는 일부 프로세스 (-es)를 종료하고 시스템이 다시 응답합니다. OOM-killer에 대한 직접 액세스는 기본적으로 활성화되어 있지 않을 수 있습니다. plz는 이 질문 을 확인하여 상태를 확인하거나 활성화하는 방법을 찾으십시오.
추신 : 이것은 많은 도움이되었습니다. Chrome 또는 기타 메모리 욕심 많은 소프트웨어로 인해 발생한 문제에 대해 가장 유용한 조언이라는 의견에 동의합니다. 그러나 OOM-killer는 중요한 프로세스를 죽일 수 있으므로주의해서 사용해야합니다.
이것은 2007 년부터 알려진 버그 입니다. 메모리 사용량이 많으면 시스템 정지를 참조하십시오 .
이 상황에서 Windows는 하나 이상의 응용 프로그램을 닫으라는 경고 대화 상자를 표시합니다.
커널을 다시 컴파일하고 싶다면 다음 질문 섹션 에서 패치 를 시도해보십시오 EDIT. /programming//q/52067753/10239615 높은 메모리 부족 상태
에서 Active(file)페이지를 제거하지 않으므로 OOM-killer를 허용합니다. 커널이 더 이상 OS를 정지시키는 모든 프로세스의 실행 가능 코드 페이지를 디스크에서 다시 읽는 데 몇 분의 시간을 소비 할 필요가 없기 때문에 거의 즉시 트리거됩니다.
이것은 특히 예방하기 어려운 것입니다. 커널이 스와핑을 시작하기 때문입니다. 한 가지 해결책은 스왑을 끄는 것입니다. 스왑을 시작하지 않고 시스템 메모리가 부족하면 커널이 일부 프로세스를 종료시킵니다. 일반적으로 올바른 프로세스를 강제 종료하여 선택하지만 응답없는 시스템을 갖는 것보다 임의 프로세스를 강제 종료하는 것이 좋습니다.
서버에 충분한 RAM이 있고 스왑 공간을 사용하기 시작하면 문제가 발생하기 때문에 이는 서버에 특히 적합한 솔루션입니다. 그러나 데스크톱에는 일반적으로 스왑 공간이 필요하므로 데스크톱에는 적합한 솔루션이 없다고 생각합니다. 특히 메모리 누수가 의심되는 경우 서버에서 종종 스왑 공간을 끕니다.