RAM (8GB)이 많기 때문에 스왑이 사용 중이거나 RAM 일 때 스왑이 사용되고 너무 많이 스왑하는 것이 좋지 않다고 들었 기 때문에 궁금합니다 ....
스왑 파티션을 만들지 않으면 어떻게됩니까?
또한 최대 절전 모드에 필요합니까?
RAM (8GB)이 많기 때문에 스왑이 사용 중이거나 RAM 일 때 스왑이 사용되고 너무 많이 스왑하는 것이 좋지 않다고 들었 기 때문에 궁금합니다 ....
스왑 파티션을 만들지 않으면 어떻게됩니까?
또한 최대 절전 모드에 필요합니까?
답변:
최신 운영 체제는 RAM을 효율적으로 사용하기 위해 스왑 공간이 필요합니다. 시스템에 충분한 RAM이 있더라도 RAM을 낭비하면 버퍼 캐시가 작아 져 디스크 I / O가 증가합니다. 따라서 RAM 용량에 관계없이 시스템에서 효율적으로 사용하기를 원합니다. 효율적으로 사용한다는 것은 접근하기 어려운 RAM에서 물건을 꺼내는 것을 의미합니다.
일반적인 시스템을 시작하면 많은 서비스가 시작됩니다. 프로그램은 초기화 코드를 실행하고 프로세스에서 개인 메모리 매핑을 수정합니다. 이러한 많은 서비스는 다시 는 실행 되지 않습니다 . 그들 중 다수는 몇 시간 동안 실행되지 않습니다. 스왑이 없으면 OS는 해당 서비스와 관련된 수정 된 개인 메모리 매핑을 RAM에 영구적으로 유지하는 것 외에는 선택의 여지가 없습니다. 디스크 캐시로는 절대 사용할 수없는 RAM입니다.
따라서 필요에 따라 스왑을 원합니다.
나는 몇 년 동안 스왑없이 데스크탑 시스템을 운영해 왔으며 계속 발전하고 있습니다! 다른 몇 가지 동작이 있습니다. 이들 중 일부는 유리하며 일부는 당신에게 해를 줄 수 있습니다. 그것은 모두 당신이하는 일에 달려 있습니다.
한 가지 큰 차이점은 메모리가 부족할 때 시스템이 작동하는 방식입니다.
스왑 파티션이 없으면 OOM 킬러가 즉시 실행됩니다. 프로그램에서 메모리 누수가 발생하는 경우 이는 사망 한 것일 수 있습니다. 그렇게되면 거의 즉시 시스템을 복구 할 수 있습니다.
스왑 파티션 이 있는 경우 커널은 메모리 내용을 스왑으로 푸시합니다. Errant 프로세스는 메모리 할당을 계속할 수 있습니다. 스왑 파티션이 큰 경우 스왑이 끝날 때까지이 문제가 계속 발생합니다. 이 작업을 수행하는 동안 시스템 속도가 느려집니다. 터미널을 열고 프로세스를 종료하는 것은 불가능합니다. 이런 일이 발생하면 보통 전원 코드를 뽑습니다.
따라서 시스템 OOM이 발생하면 어쨌든 데이터가 손실 되므로 이전 옵션은 적어도 (높은) 복구 가능성을 갖는 것을 선호합니다.
스왑 영역이 성능에 부정적인 영향을 준다고 생각하는 것은 일반적인 오해입니다. 성능에 심각한 영향을 미치는 것은 충분한 RAM이없는 것입니다. 스왑 영역 자체는 안정성에 신경 쓰지 않는 한 성능에 부정적인 영향을 미치지 않습니다. 충분한 RAM이 있고 RAM 부족이보고되지 않은 경우에도 성능에 긍정적 인 영향을 줄 수 있습니다 .
고려해야 할 세 가지 경우가 있습니다.
1 : 내부 커널 요구에 충분한 RAM이 있으며 모든 응용 프로그램이 RAM에 작업 페이지 세트를 가지고 있고 버퍼 캐시가 대부분의 파일 시스템 핫 데이터를 저장할 수있는 "사용 가능한"RAM을 가지고 있습니다.
2 : 버퍼 캐시를 완전히 효율적으로 사용할 수있는 충분한 여유 RAM이 없다는 점을 제외하면 위와 동일합니다.
3 : 응용 프로그램이 사용한 페이지를 저장할 수있는 충분한 RAM이 없습니다.
생산 영역의 표준이되어야하는 경우 1 인 경우 (스왑 영역이 있거나 변경하지 않음) (최소한 Linux 기반 OS 및 메모리를 초과 커밋하는 다른 OS)
사례 2의 경우 스왑 영역이 있으면 시스템에서 자주 사용하지 않는 페이지를 페이지 아웃 한 다음 버퍼 캐시가 더 나은 역할을 수행 할 수 있도록하여 전체 성능을 향상시킬 수 있습니다 .
사례 3의 경우 스왑 영역이 있으면 페이지 매김으로 인한 성능 저하가 발생하여 애플리케이션이 계속 실행됩니다. 반면에 스왑 영역 (또는 충분히 큰 영역)이 없으면 응용 프로그램이 임의로 중단됩니다. 또한 OS 설정에 따라 OOM 킬러는 RAM이 많이 필요한 경우 중요한 데이터를 저장할 수있는 기회를 제공하지 않으면 서 메모리 사용량이 많은 응용 프로그램을 종료 할 수도 있습니다.
후자의 경우는 함께 선택해야합니다. 응답 시간이 중요하고 트랜잭션 / 프로세스 손실이 큰 영향을 미치지 않는 시스템과 같이 프로세스를 강제 종료하는 것이 선호되는 옵션 인 경우가 있습니다.
그러나 대부분의 상황에서 사용자 / 관리자가 RAM 부족을 인식하고 데이터 손실의 위험없이 그에 따라 조치를 취할 수 있도록하는 것이 좋습니다.
스왑 파티션을 사용하지 않으려는 경우 스왑 파일 (일반 파일에 저장되고 스왑 공간으로 사용되는 파일 시스템 이미지)을 사용할 수 있습니다.
다음 기사에서는이를 수행하는 방법을 자세히 설명합니다.
조금 위험하지만 스왑 공간없이 실행할 수 있습니다. 그러나 마지막으로 메모리 양을 초과하면 시스템이 거의 즉시 통지없이 충돌합니다.
스왑이 기본적으로 제공하는 것은 확장되었지만 훨씬 느린 메모리입니다. 초과하면 스와핑이 시작되어 시스템의 수명이 실제로 단축됩니다 .... 그러나 잘못된 프로세스를 종료하면 시스템을 계속 저장할 수 있습니다.
일부 프로그램은 스왑 공간을 할당 (사용하지는 않음)해야한다고 주장합니다. 다시 한 번 스왑 공간이 없으면 실행 가능한 프로그램이 제한 될 수 있습니다.
마지막으로이 영역을 백업 할 필요가 없다는 점에서 SWAP이 저렴합니다. (귀하의 시스템을 백업하는 뛰어난 시스템 관리자 중 한 분이기를 바랍니다.)
그래서 그것을 만드십시오.
내 경험 법칙은 2 * memory-size였습니다 .....하지만 지금은 많은 경우에 1 * memory-size로는 괜찮지 만 일반적으로 1.5 * (memory-size)를 사용합니다. 이 정도의 양을 만들 필요는 없지만 특히 생산중인 작업 유형이있는 경우 특히 그렇습니다.
예, 최대 절전 모드의 경우 전체 메모리 이미지를 보유하려면 스왑이 필요합니다. 따라서 h8ibernation을 고려하는 경우 크기는 AT LEAST (1 * memory-size) + 100MB 여야합니다. 100MB는 프로세스에 필요한 오버 헤드를위한 것입니다.
메모리 스왑이 발생하자마자 Linux 스왑은 매우 어려운 요구 사항으로 보입니다. 증상은 거의 모든 RAM이 활성 프로세스에서 사용되는 경우 시스템이 정지되고 하드 디스크가 야생 상태로 실행된다는 것입니다.
왜?
스왑이 없을 때 백업 파일이없는 페이지 (일반적으로 동적 메모리 할당의 페이지)는 RAM에서 제거 할 수 없습니다. 커널은 실제로 다시 필요한 경우에도 백업 파일이있는 페이지를 사용합니다. i. 이자형. 스왑 없이도 휴지통!
이 미묘한 문제에 대한 자세한 내용은이 블로그 게시물을 참조하십시오.
결론 : 항상 스왑이 있습니다.
대략적인 지침으로 크기를 설정하려면 최대 절전 모드가 아니라고 가정하고 RAM이 많은 시스템의 경우에도 4GB에서 8GB 사이의 값을 사용하십시오. 자세한 내용 은 스왑 공간에 대한 Red Hat의 설명서를 참조하십시오 .