Linux 시스템을 설정하려고 할 때 스왑 공간을 실제 메모리의 두 배로 설정하는 것이 일반적입니다. 나는 이것이 왜 필요한지, 그리고 이 제안이 어떻게 이루어졌는지 알고 싶습니다.
답변1
짧은 대답은 "당신은 그렇지 않습니다.가지다에게".
커널/시스템 유형에 따라 FreeBSD와 같이 스왑 공간의 크기를 조정하는 것이 합리적일 수 있습니다.튜닝(7)맨페이지에서는 스왑 크기를 실제 메모리 크기의 2배 이상으로 설정한 다음과 같은 근거를 찾을 수 있습니다.
일반적으로 RAM이 2GB 미만인 시스템의 경우 주 메모리의 약 2배, RAM이 더 많은 경우 주 메모리의 약 1배로 스왑 공간 크기를 조정해야 합니다. 그러나 RAM이 많지 않은 경우에는 일반적으로 더 많은 스왑을 원하게 됩니다. 시스템에서 256M 미만의 스왑을 구성하는 것은 권장되지 않으며 스왑 파티션 크기를 조정할 때 향후 메모리 확장을 염두에 두어야 합니다. 커널의 VM 페이징 알고리즘은 메인 메모리에 비해 최소 2배의 스왑이 있을 때 최상의 성능을 발휘하도록 조정되었습니다. 스왑을 너무 적게 구성하면 VM 페이지 스캔 코드의 비효율성이 발생할 수 있으며 나중에 시스템에 메모리를 추가하면 문제가 발생할 수 있습니다. 마지막으로 여러 개의 SCSI 디스크(또는 서로 다른 컨트롤러에서 작동하는 여러 IDE 디스크)가 있는 대규모 시스템에서는 각 드라이브에 스왑을 구성하는 것이 좋습니다. 드라이브의 스왑 파티션 크기는 대략 동일해야 합니다. 커널은 임의의 크기를 처리할 수 있지만 내부 데이터 구조는 가장 큰 스왑 파티션의 4배까지 확장됩니다. 스왑 파티션을 동일한 크기에 가깝게 유지하면 커널이 N 디스크에 걸쳐 스왑 공간을 최적으로 스트라이프할 수 있습니다. 조금 과도하게 사용하는 것에 대해 걱정하지 마십시오. 스왑 공간은 UNIX의 절약 은혜이며 일반적으로 많은 스왑을 사용하지 않더라도 강제로 재부팅되기 전에 런어웨이 프로그램에서 복구하는 데 더 많은 시간을 제공할 수 있습니다.
할당할 스왑 공간의 양, 할당할 위치 등을 결정할 때 다른 요소가 중요할 수 있습니다. 예를 들어, 128GB의 물리적 메모리가 있는 대규모 서버를 설치하는 경우 결코 사용되지 않을 스왑을 위해 256GB의 디스크 공간을 미리 할당하지 않는 것이 좋습니다.
반면에,일부스왑 공간을 사용하면 커널 덤프를 얻을 수 있는 경우가 많습니다(예: Open-, Net- 및 FreeBSD에서). 따라서 패닉 상태에서 전체 커널 덤프를 확보할 수 있을 만큼 최소한 충분한 스왑 공간을 확보하는 것이 좋습니다.
딱 맞는 절대적인 법칙은 없어요모두사례. 특정 시스템의 동작을 읽고, 작동 방식을 배우고, 시스템의 의도된 용도에 대해 생각하고, 적합한 스왑 공간의 최적 크기를 결정해야 합니다.당신의필요합니다.
답변2
전혀 그럴 필요가 없습니다. 이전 버전의 Windows는 할당된 메모리의 각 페이지를 본질적으로 스왑 파일의 mmap으로 처리하므로 이를 유용하게 사용하려면 스왑에 최소한 총 실제 RAM 크기가 필요했습니다. 오늘날에는 더 이상 그렇지 않으며 결코 그렇지 않습니다. Linux의 경우이지만 소문은 계속됩니다.
그러나 최소한 RAM만큼의 스왑을 갖는 것이 바람직한 경우가 있습니다. 바로 최대 절전 모드입니다. Linux는 최대 절전 모드(즉, 디스크 일시 중지)를 위해 스왑 파일을 사용하므로 RAM의 모든 데이터와 이미 스왑 아웃된 모든 데이터(캐시 RAM 제외)를 보관할 만큼 충분한 스왑이 필요합니다. 물론 이는 랩탑과 같이 최대 절전 모드가 필요한 시스템의 경우에만 해당됩니다.
마지막으로 스왑이 너무 많으면 문제가 될 수 있습니다.나쁜다른 사람들이 뭐라고 말하더라도. 생각해 보십시오. RAM이 4G이고 추가로 8G의 스왑이 필요한 경우 시스템을 계속 사용할 수 있다고 생각하십니까? 디스크와의 모든 스왑 작업은 어떻게 됩니까? 스왑 안팎으로 데이터를 마샬링하는 데 모든 시간을 소비하기 시작할 때 전체 시스템이 사용할 수 없는 수준으로 느려지는 것보다 메모리가 부족할 때 메모리를 많이 차지하는 프로세스를 즉시 종료하는 것이 더 나은 경우가 많습니다.
답변3
오래 전에 스왑 공간에 모든 가상 메모리 페이지를 할당하는 일반적인 유닉스 변형(BSD인 것 같지만 지금은 참조를 찾을 수 없음)이 있었습니다. 따라서 RAM만큼 스왑이 있었다면 가상 메모리의 크기는 여전히 RAM과 동일합니다. 당시 일반적인 권장 사항은 RAM보다 두 배 많은 스왑을 확보하여 가상 메모리를 RAM보다 두 배 크게 만드는 것이었습니다.
현대의 유니스는 그런 식으로 동작하지 않으므로 이 규칙의 이유는 더 이상 사용되지 않습니다(내 생각에는 1992년에 이미 사용되지 않았으므로 Linux와는 전혀 관련이 없습니다). 그러나 이상하게도 그 규칙은 살아남았습니다. 지금 따라가면 RAM 용량의 3배에 해당하는 가상 메모리를 얻게 됩니다. 원래 의도는 2배를 확보하는 것이었습니다.
규칙의 역사적 이유가 잘못되었다고 해서 그것이 어리석다는 의미는 아닙니다. 디스크 공간이 저렴해졌으므로 더 많은 스왑을 할당하는 것이 합리적일 수 있습니다. 얼마나 많은 스왑이 있어야 하는지는 가지고 있는 RAM의 양과 사용 방법에 따라 크게 달라집니다. 스왑 없이 시스템을 실행할 수 있지만 RAM이 가득 차면 어떤 프로그램을 종료할지 선택할 수 없으며 시스템 속도가 느려질 수 있습니다(때로는 RAM을 캐시로 사용하고 일부 프로그램 메모리를 스왑하는 것이 더 나음) 밖으로). 스왑을 너무 많이 할당하면 소량의 RAM(커널 데이터 구조용)과 디스크 공간이 소모됩니다(그러나 요즘에는 SSD를 제외하면 일반적으로 매우 저렴합니다). 최대 절전 모드로 전환하려면 모든 가상 메모리를 수용할 만큼 충분한 스왑이 필요합니다.
답변4
일반적인 시스템 메모리 용량, 메모리 버스 속도 대 디스크 속도, 프로세스가 다양한 대기 상태에서 소비하는 시간 비율에 대한 가정을 기반으로 한 고대 권장 사항입니다. 요즘에는 스왑 공간에 물리적 메모리의 1/2 이상을 원할 것이라는 데 회의적입니다. 전체 메모리 활용에 가까워질 때 임의의 OOM 종료를 방지할 수 있을 만큼만 충분합니다. 그러나 전적으로 일반적인 작업량, YMMV 등에 따라 다릅니다.