다른 답변 외에도 프로그램에서 메모리를 사용하지 않더라도 할당 된 메모리를 백업하도록 Linux를 구성 할 수 있습니다.
그러나 메모리를 과도하게 커밋하고 OOM 킬러를 두려워하는 것은 Linux 경험에서 필요하지 않은 부분입니다. sysctl 매개 변수 vm / overcommit_memory를 2로 설정하면 오버 커밋 동작이 꺼지고 OOM 킬러가 계속 베이크 상태로 유지됩니다. 대부분의 최신 시스템에는 대부분의 상황에 충분한 스왑 파일을 제공 할 수있는 충분한 디스크 공간이 있어야합니다. 오버 커밋 된 메모리가 부족할 때 pet 프로세스가 종료되지 않도록하는 대신 상황을 완전히 피하는 것이 더 쉬울 수 있습니다. [ OOM 킬러로부터의 휴식 ]
프로그램이 메모리를 할당하면 커널은 더 많은 스왑 페이지를 커밋 된 것으로 표시 할 수 있습니다. 이 표시는 커널의 메모리 관리자에 저장되며 실제 디스크 공간은 아직 건드리지 않았습니다. 해당 메모리가 사용될 때까지 실제로 스왑 및 스왑 할 필요는 없습니다. 이들이 사용되지 않으면 스왑 사용량은 성능에 영향을주지 않으면 서 변동합니다.
프로세스에는 자체 주소 공간 또는 "보기"(스왑이 처음부터 작동하는 방식)가 표시되므로 커널은이를 관리하는 방법에 많은 여유가 있습니다. 위에 링크 된 기사의 포크 예제를 사용하면 사용되지 않은 많은 양의 메모리를 새로 할당하는 것보다 공유 메모리 페이지가 훨씬 많기 때문에 메모리에 쓰기 중 복사가 할당되어 스왑 사용 횟수가 증가합니다. 실제로 작성된 경우 (발생하지 않을 수도 있음) "커밋 된 스왑"을 사용되지 않은 RAM (RAM 사용 증가 및 스왑 사용 감소)으로 바꿀 수 있습니다. 전체 또는 거의 모든 RAM을 사용하는 머신에 500MB가 할당 된 프로세스를 상상해보십시오. 스왑에 사용 가능한 500MB가 있고 디스크 공간이 저렴하면 오늘날의 TB 드라이브의 1 %가 얼마나됩니까? : P) 메모리를 복사 할 필요가 없습니다 (아직,
따라서 OOM 킬러의 가능성을 피할 수 있으며 메모리 할당 (포크와 같은 것을 통한 "암시 적"할당 포함)을 통해 메모리 할당이 성공해야한다고 가정하고 대부분의 소프트웨어를 설계하는 것이 훨씬 간단합니다. 교환하면 성능에 영향을 줄 수 있습니다. 이러한 영향은 거의 항상 미미하지만 최악의 경우 스왑을 발생시킵니다 (아직 완전한 커널 충돌 또는 OOM 킬러보다 선호되는 경우도 있음).
Linux 메모리 관리자의 작동 방식에 대한 정확한 세부 정보는 모르지만이 답변은 제 자신의 일반적인 이해와 몇 년 동안 읽은 것을 기억합니다. 나는이 답변을 다시 편집하려고 노력했기 때문에 OS 디자인에 대한 최소한의 이해가 필요합니다 (매우 복잡하고 관심이있는 것은 아닙니다). 어떻게 개선 될 수 있는지 알려주세요. 손에 쥐는 것은 그렇게 창피한 기본적인 질문이 아닐 수도 있습니다.