스왑 파일에 대한 토론("만들어야 할까요?")에서 "어떤 경우에는 스왑 파일이 득보다 해를 끼칠 수 있습니다"라는 모호한 언급을 자주 봅니다. 이것은 일반적으로 "XGB 이상의 RAM이 있으면 스왑이 필요하지 않습니다"와 함께 진행되며 일반적으로 확실한 주장으로 지원됩니다. 그렇다면 다음과 같은 명백한 반론이 있습니다.여기.
foo즉각적인 메모리 액세스에 따라 올바른 기능이 달라지는 백그라운드에서 실행되는 애플리케이션이나 서비스를 상상할 수 있습니다 . 스왑에 사용되는 메모리 공간을 제거하면 foo해당 공간에 대한 액세스 속도가 느려지고 foo경고, 오류 또는 전체 오류가 발생합니다.
그러나 이것이 내가 얻은 것입니다. 실제 사실은 파악하기 어렵습니다. 예를 들어, 내 Linux 상자에는 64GB RAM이 있어 여러 가상 머신을 동시에 실행할 수 있습니다. 이 시점에서 많은 Linux 사용자는 전혀 교체하지 않기로 결정했지만 만일을 대비하여 16GB를 유지했습니다. 드라이브 공간은 저렴하지만 클래식은 swap = 2x RAM약간 과장된 것 같습니다.
- UNIX/Linux 세계의 실제 사례를 들어줄 수 있는 사람이 있습니까? RAM이 많은 시스템에서 스왑 파일을 사용하면 실제로 원치 않는 결과가 발생할 수 있으며, 그러한 결과는 어떻게 될까요?
- 스왑 파일 대신 별도의 스왑 파티션을 사용하면 상황이 바뀌나요?
- user10489의 답변에 따르면 *NIX와 유사한 OS:s에는 Windows에서 사용하는 것과 유사한 별도의 최대 절전 모드 파일이 없습니까?
명확히 하기 위해: RAM/스왑 비율 또는 스왑을 먼저 할당해야 하는지 여부는 질문의 범위를 벗어납니다.
답변1
교환은 특정 실패 사례를 영속시킬 수 있으므로 나쁠 수 있습니다.더 길게. 버그, 잘못된 구성 또는 기타 이유로 인해 일부 프로세스가 너무 많은 메모리를 사용하기 시작하는 상황을 생각해 보십시오. 스와핑을 하지 않으면 결국 시스템의 메모리가 부족해지며 결국 운영 체제는 프로세스를 종료하여 문제를 해결하게 됩니다. (그러나 어쨌든 다른 문제가 발생할 수 있습니다.)
그러나 스왑 공간이 많으면 프로세스가 스왑 공간을 소비하기 시작하고 주 메모리와 스왑 공간 사이에서 페이지를 스래싱하여 모든 속도가 느려질 수 있습니다. 시스템은 결국 메모리가 부족해지게 되지만, 메모리가 부족해지기까지 오랜 시간 동안 고통을 겪게 될 것입니다.
나는 주로 느린 스왑 장치, 즉 회전하는 녹슨 디스크에 대해 생각하고 있습니다. 왜냐하면 그것이 내가 직면한 것이기 때문입니다... 이것은 최신 고속 SSD에서는 문제가 되지 않을 수 있습니다.
(물론 올바른 해결책은 프로세스당 메모리 사용량에 제한을 두는 것이지만 이러한 제한이 없으면 일반적인 임의 데스크탑 시스템처럼 스왑 공간이 존재하는지 여부가 영향을 미칠 수 있습니다.)
스왑이 좋은지 나쁜지에 대해서는 언급하지 않겠습니다.일반적으로 말하면, 단지 가능한 상황입니다. 또한 비율 등에 대해서는 언급하지 않습니다. 이는 종종 일반화되었으며 더 이상 유효하지 않은 요구 사항을 기반으로 할 수 있습니다.
답변2
기술적으로 말하면 스왑 파티션은 스왑 파일보다 효율적입니다. 사실 스왑 파일이 연속되어 있다면 큰 차이가 없어야 하고, 현재 버전의 리눅스와 성능 차이도 전혀 없어야 합니다. 스왑 파일에는 몇 가지 버그가 있지만 이상한 상황에서만 발생합니다.
스와핑이 득보다 해를 끼치는 경우는 전적으로 시스템의 작업 부하에 달려 있습니다. 시스템 작업 부하로 인해 스왑이 사용되지 않는 경우에는 문제가 없습니다. 프로그램이 많은 메모리를 할당하고(스왑으로 끝남) 다시는 사용하지 않는 경우(메모리 누수?) 스와핑은 많은 도움이 될 수 있습니다.
그러나 실행 중인 모든 작업의 총 작업 세트 크기(프로그램이 물리적 메모리에 필요한 크기)가 물리적 메모리보다 크고 일부 오버플로가 스왑에서 끝나면 시스템이 충돌하여 지속적으로 Swap으로 푸시하고 다른 항목을 로드하려고 시도합니다. 물건을 다시. 이로 인해 시스템 성능이 정상의 1/10이 될 수 있으며 시스템이 잠겨 있고 교체하지 않으면 무언가가 OOM 종료된 것처럼 느껴질 수 있습니다.
시스템이 느리고 혼란스러워지는 것이 더 나은지, 아니면 무언가를 죽이고 시스템 성능이 더 정상적인 상태로 돌아가는 것이 더 나은지는 논쟁의 여지가 있으며 사례별로 다릅니다.
이를 초과하는 메모리/스왑 비율을 할당하려는 분석이나 시도는 사례별로 또는 의견에 따라 결정됩니다.
스왑은 최소한 메모리만큼의 스왑이 필요하고 크래시 덤프가 필요한 최대 절전 모드와 같은 다른 목적으로도 사용됩니다.
위의 모든 사항이 특히 Linux에 적용된다는 점을 덧붙이고 싶습니다. 일부 유닉스 버전은 특히 모든 램을 숨기기에 충분한 스왑 공간이 필요하며, 그 위에 가상 메모리를 추가하려면 램보다 더 많은 스왑 공간이 필요합니다. 현재 Linux는 스왑 없이도 잘 실행됩니다. 일부 유닉스에서는 스왑이 필요하지 않으며 초기 버전의 Linux에서도 스왑이 필요합니다.
답변3
부적절한 미디어 교체
스왑으로 사용되는 SD 카드는 제한된 쓰기 주기로 인해 조기에 심각하게 오류가 발생하는 경향이 있습니다. 이는 제한된 USB 대역폭, 저렴한 SD 카드 및 제한된 메모리로 인해 초기 Raspberry Pi 설정에서 특히 문제가 되었습니다.
답변4
올바른 기능은 즉각적인 메모리 액세스에 따라 달라지는 애플리케이션이나 서비스 foo가 백그라운드에서 실행되는 것을 상상할 수 있습니다. foo가 스왑에 사용하는 메모리 공간을 제거하면 메모리 공간에 대한 액세스 속도가 느려지고 foo 자체도 느려지므로 경고, 오류 또는 심지어 완전한 실패가 발생합니다.
이 추론은 잘못되었습니다. 이 추론에는 암묵적인 가정이 포함되어 있습니다. 즉, 스왑에 무언가를 넣는 것과 물리적 RAM에서 이를 폐기하는 것은 동일합니다. 어느 쪽이든 다른 쪽 없이도 일어날 수 있습니다.
클린 페이지는 스왑에 기록되지 않고 RAM에서 삭제될 수 있습니다. 스왑 파일이 없더라도 이런 일이 발생할 수 있습니다. 따라서 기능이 즉각적인 메모리 액세스에 의존하는 프로그램은 스왑 파일 없이도 해당 코드 페이지가 RAM에서 삭제되기 때문에 망가질 수 있습니다. 실제로 이는 스왑 파일 없이 발생할 가능성이 더 높습니다. 스왑 파일이 없으면 더티 페이지를 삭제할 수 없기 때문입니다. 즉, 클린 페이지(예: 코드)가 물리적 RAM에 존재하지 않을 가능성이 더 높습니다.
스왑에 작성된 페이지가 반드시 물리적 RAM에서 삭제되는 것은 아닙니다. 페이지는 스왑 RAM과 물리적 RAM에 존재할 수 있습니다. 페이지는 물리적 RAM이나 스왑에 위치할 수 있습니다.
이 두 가지 때문에 위의 주장은 의미가 없습니다. 스와핑을 사용하면 오랫동안 액세스하지 않은 더티 페이지를 물리적 RAM에서 꺼낼 수 있습니다. Swap을 하지 않으면 오랫동안 방문하지 않은 클린 페이지가 없더라도 클린 페이지만 팝업될 수 있습니다.
스왑 여부에 관계없이 중요한 프로세스가 RAM에서 데이터를 찾는다는 보장은 없습니다. 그러나 스와핑이 있는 경우 데이터가 RAM에서 발견될 가능성이 더 높습니다. 왜? RAM에서 무언가를 찾을 수 있는지 여부는 시스템의 작업 세트가 RAM에 맞는지 여부에 따라 달라지기 때문입니다. 스와핑은 한 번도 액세스한 적이 없는 작업 세트에서 더티 페이지를 제거하여 크기를 줄이고 RAM에 들어갈 가능성을 높입니다.