다음 시나리오를 고려하십시오. 2GiB의 호스트는 KVM을 사용하여 몇 개의 게스트를 실행합니다. 각 게스트에는 일반적으로 많은 메모리가 필요하지 않습니다. 그들은 각각 256MiB를 부여받고 대부분 엄지손가락을 조작하는 서비스를 실행합니다. 그러나 게스트에게 더 많은 메모리가 필요한 경우도 있습니다. 현재 각 게스트에는 RAM이 거의 없지만 자체 스왑 공간이 있습니다. 스왑의 작은 부분이 사용되는 것으로 나타났습니다. 해당 구성에는 문제가 없었지만 단지 호기심 때문이었습니다.
최적의 스왑 할당 전략은 무엇입니까?
- 각 게스트에게 해당 디스크에서 고유한 스왑 공간을 할당하고 게스트에는 호스트에서 약간의 메모리만 할당합니다. (이것이 내가 지금 하고 있는 일이다.)
- 호스트에 더 많은 양의 스왑 공간을 할당하고 게스트에는 할당하지 않고 게스트에는 더 많은 메모리를 할당합니다.
메모리 벌루닝이 메모리 성능을 향상시키는 데 도움이 될까요?
답변1
"가끔 게스트에게 더 많은 메모리가 필요할 때가 있습니다"라는 말은 다음을 잘 적용한 것처럼 들립니다.메모리 오버커밋. 아이디어는 일반적으로 게스트가 메모리를 사용하지 않기 때문에 각 게스트에게 많은 양의 메모리(실제로 제공할 수 있는 것보다 더 많은 양)를 할당하는 것입니다. 그런 다음 게스트가 실제로 최악의 시나리오에서 디스크로 교체할 수 있는 충분한 스왑 공간이 있는지 계산을 수행합니다.하다그 메모리를 모두 사용하세요.
스왑 공간은주인기계는 복종해야 합니다.
호스트 스왑 공간 = 모든 게스트 메모리의 합계 + 권장 호스트 스왑 공간
안전하기 위해서입니다.
따라서 게스트가 10명이고 RAM이 2GiB라면 다음과 같이 실험해 볼 수 있습니다.
- 게스트당 512MiB RAM(512 * 10 = 총 5120MiB)
- 호스트에서 2GiB 스왑
즉, 2GiB의 스왑을 호스트에 전용으로 할당할 수 있다고 가정할 때 이를 안전하게 처리하려면 호스트 스왑 공간이 최소 512 * 10 + 2048 = 7168MiB여야 합니다(작은 호스트 메모리의 경우 이것이 권장됨).
항상 이러한 종류의 설정을 먼저 테스트하여 컴퓨터가 이러한 설정을 처리할 수 있는지 확인하십시오. 이를 벤치마킹하는 것이 훨씬 더 좋으며 다양한 로드아웃을 실험하고 가장 적합한 로드아웃을 선택할 수 있습니다.
답변2
@ndt는 좋은 절차를 가지고 있습니다. 내 시나리오가 다르기 때문에 다른 방법을 채택합니다.
내 서버에는 많은 게스트가 있으며, 모두 단일 애플리케이션, 일반적으로 웹/메일/파일 서버를 실행합니다. 내부의 데이터는 매우 중요하므로 백업과 스냅샷이 매우 자주 만들어집니다. 따라서 디스크 이미지는 더 작고 단순할수록 좋습니다. 그래서 실제로는 스왑 파티션을 만들지 않고 스왑 파일을 만듭니다. 처리량이 높거나 메모리가 필요한 게스트가 없기 때문에 디스크 저장 공간과 메모리도 작습니다. 스왑 파일은 rootfs 내부에 들어갑니다.
이 설정은 많은 공간을 절약하고 유지 관리를 단순화합니다. 내가 말했듯이 다른 상황과는 다릅니다.
답변3
허용되는 답변이 잘못되었습니다.
또한 VM에서 스왑 공간을 활성화해야 RAM이 스왑되고 있음을 인식하고 이를 디스크 캐시 및 IO 버퍼에 사용하지 않도록 해야 합니다.
호스트에서만 스왑을 활성화하면 VM은 사용 가능한 실제 RAM이 있다고 믿고 이를 사용하는 반면, 호스트에서는 스왑되어 불필요한 병목 현상이 발생하고 정지됩니다. 이것은 당신이 할 수 있는 가장 큰 실수입니다.
또한 다른 데이터 드라이브와 함께 스냅샷/백업을 수행하고 싶지 않으므로 다른 가상 드라이브를 스왑 디스크로 사용해야 합니다.
스왑 공간은 일시적일 수 있으므로 더 나은 성능을 위해 캐시=안전하지 않거나 zram/zswap을 사용할 수도 있습니다.
또한 스와핑은 나중에 디스크 캐시 및 IO 버퍼에 재사용할 수 있는 비활성 RAM을 확보하므로 좋은 점을 기억하십시오.