nginx(또는 안정적인 리소스 사용이 가능한 기타 경량 데몬)를 실행하는 Linux VM. VM에는 2GB의 메모리가 할당되며, 그 중 200-300MB는 운영 체제 및 서비스에 사용되고 나머지는 파일 캐시 및 버퍼에 사용됩니다. 특정 사용 사례에서는 오버헤드가 쉽게 500MB에 도달할 것으로 예상됩니다.
묻다:이 설정에 스왑 공간이 필요한 이유는 무엇입니까?
"메모리 고갈 방지"라는 표준 대답은 다음 두 가지 이유로 이해가 되지 않습니다.1:메모리 요구 사항은 이미 설정되어 있으므로 예상치 못한 또는 갑작스러운 상당한 증가를 지원할 필요가 없습니다.2:그럼에도 불구하고 교체는 OOM 상황을 지연시킬 뿐입니다. 가상 머신에 더 많은 메모리를 먼저 할당함으로써 동일한 작업을 수행할 수 있습니다. 특히 가상 머신이 씬 프로비저닝되어 있고 사용하지 않는 한 누구도 놓치지 않을 것이기 때문입니다.
최대 절전 모드 지원에 대한 또 다른 일반적인 대답은 가상 머신의 서버에는 적용되지 않습니다.
이와 같은 서버에서 스왑을 수행할 이유가 없습니다. 제가 뭔가를 놓치고 있는 걸까요?
답변1
"스왑 여부"에 대해 생각해서는 안 됩니다. 전반적인 메모리 할당 전략을 생각하고 스왑이 필요한지 결정해야 합니다. 여기에는 두 가지 주요 측면이 있습니다.
오늘날 스왑의 주요 목적은 물리적 메모리를 확장하는 것이 아니라 재활용할 수 없는 다른 페이지에 백업 스토리지를 제공하는 것입니다(예를 들어메모리 할당 및 익명성 mmap
). 스왑 없이 실행하면 커널이 물리적 메모리에 익명 메모리를 유지하게 되어 변화하는 메모리 수요에 대처하는 능력이 저하됩니다. 물론, 자신의 업무량을 알고 있다면언제나사용 가능한 실제 메모리에 적합하며 이는 문제가 되지 않습니다.
고려해야 할 두 번째 측면은 커널의 오버커밋 정책입니다. 기본적으로 메모리 할당은 메모리 로드에 관계없이 대부분 성공합니다. 작업 부하를 제어하려는 경우 검사 모드( /proc/sys/vm/overcommit_memory
2로 설정)에서 실행하는 것이 도움이 되는 경우가 많습니다. 그러면 커밋 제한은 대용량 페이지에 할당되지 않은 스왑 공간과 물리적 메모리의 합계이며 오버커밋 비율(기본값)로 제한됩니다. 50%) 조정을 수행합니다. 스왑 없이 실행하는 경우 기본적으로 물리적 메모리의 절반 이상을 할당할 수 없습니다. 스왑을 추가하면 제한이 선형적으로 증가하며 오버커밋을 늘리는 것보다 덜 위험합니다. (이것은 일반적인 서버 설정에서 대규모 JVM을 실행하려고 할 때 사람들을 혼란스럽게 만드는 경우가 많습니다.)
위에서 언급한 것처럼 두 가지 주요 측면이 있다고 언급했지만 어떤 경우에는 고려해야 할 또 다른 사항이 있다는 생각이 들었습니다(실제로는 첫 번째 사항의 변형입니다). tmpfs
파일 시스템이 시스템을 쉽게 정체시킬 수 있는 경우, 교환은 안돼...
이 모든 것에 대한 자세한 내용을 보려면 다음을 읽어 보는 것이 좋습니다.proc(5)
맨페이지남용에 관한 섹션, 그리고Chris Down의 최근 블로그 게시물은 교환을 옹호합니다..
답변2
당신은하지 않습니다필요공간을 교환하지만 언급하지 않았지만 명심해야 할 몇 가지 사항이 있습니다. 일부 페이지는 시스템 시작 시 로드되어 다시는 건드리지 않습니다. 성능 향상은 미미할지라도 메모리보다는 디스크에 보관하는 것이 더 낫다는 점은 틀림이 없습니다.
이와 관련하여 일부 워크로드(예: JVM)는 결코 사용되지 않을 많은 양의 메모리를 할당합니다. 업무량이 습관적으로 과부하되면 목욕물과 함께 아기를 버릴 수도 있습니다. 커널을 물리적 메모리로 제한한다는 것은 a) VM에 필요한 것보다 더 많은 RAM을 할당하거나, 다른 VM에 할당될 수 있는 서버 리소스를 낭비하거나, b) 사용되지 않은 상태로 유지하기 위해 커널이 버퍼 수를 줄이게 한다는 것을 의미할 수 있습니다. 또는 거의 사용되지 않음) 할당된 페이지는 디스크 활동을 증가시켜 전반적인 성능을 저하시킬 수 있습니다.
스왑을 활성화하지 않으면 디버깅을 위해 시스템에 로그인해야 하는 경우 오버헤드가 이상하게 사라지는 것을 발견할 수 있습니다. 효과적으로 시스템에 한 번만 로그인하면 되는 시스템은 엄격한 부팅 메모리 제한과 메모리 누수를 결합하여 보다 자유로운 스왑 공간 정책을 장려합니다. 기계에서 무엇이든 하는 데 한 시간을 보내는 것은 지속적으로 OOM 킬러를 실행하는 것과 비교하면 여전히 개선된 것입니다.
마지막으로 Unix 시스템에서 코어 덤프를 스왑에 배치하는 것은 드문 일이 아닙니다. 상당수의 관리자는 여전히 커널 패닉을 디버깅하기 위해 충분한 스왑 공간을 할당합니다. (분명히 Linux는 이제 이 문제를 해결할 수 있는 방법을 제공합니다.)