VMware vSphere의 VM 성능 분석. 파트 2: 메모리

1부. CPU에 대하여

이 기사에서는 vSphere의 RAM(Random Access Memory) 성능 카운터에 대해 설명합니다.
메모리를 사용하면 프로세서보다 모든 것이 더 명확해 보입니다. VM에 성능 문제가 있는 경우 이를 알아채지 못하는 것이 어렵습니다. 그러나 그들이 나타나면 처리하기가 훨씬 더 어렵습니다. 하지만 먼저 해야 할 일이 있습니다.

약간의 이론

가상 머신의 RAM은 VM이 실행 중인 서버의 메모리에서 가져옵니다. 아주 분명합니다 :). 서버의 RAM이 모든 사람에게 충분하지 않은 경우 ESXi는 메모리 회수 기술을 사용하여 RAM 소비를 최적화하기 시작합니다. 그렇지 않으면 VM 운영 체제가 RAM 액세스 오류로 충돌합니다.

ESXi를 사용할 기술은 RAM 부하에 따라 결정됩니다.

메모리 상태

경계

활동

높은

minFree의 400%

상한선에 도달하면 대용량 메모리 페이지가 작은 페이지로 분할됩니다(TPS는 표준 모드에서 작동함).

초기화

minFree의 100%

큰 메모리 페이지는 작은 페이지로 나뉘고 TPS는 강제로 작동합니다.

부드러움

minFree의 64%

TPS + 풍선

하드

minFree의 32%

TPS + 압축 + 스왑

낮은

minFree의 16%

압축 + 스왑 + 차단

출처

minFree는 하이퍼바이저가 작동하는 데 필요한 RAM입니다.

ESXi 4.1 포함 이전에는 minFree가 기본적으로 서버 RAM의 6%로 고정되었습니다(백분율은 ESXi에서 Mem.MinFreePct 옵션을 통해 변경할 수 있음). 이후 버전에서는 서버의 메모리 크기 증가로 인해 minFree가 고정된 백분율이 아닌 호스트 메모리 양을 기준으로 계산되기 시작했습니다.

minFree(기본값) 값은 다음과 같이 계산됩니다.

minFree용으로 예약된 메모리 비율

메모리 범위

6%

0~4GB

4%

4~12GB

2%

12~28GB

1%

남은 메모리

출처

예를 들어, 128GB RAM이 있는 서버의 경우 MinFree 값은 다음과 같습니다.
최소 무료 = 245,76 + 327,68 + 327,68 + 1024 = 1925,12MB = 1,88GB
실제 값은 서버와 RAM에 따라 수백 MB 정도 다를 수 있습니다.

minFree용으로 예약된 메모리 비율

메모리 범위

128GB의 가치

6%

0~4GB

245,76MB

4%

4~12GB

327,68MB

2%

12~28GB

327,68MB

1%

남은 메모리(100GB)

1024MB

일반적으로 생산성 스탠드의 경우 높음 상태만 정상으로 간주할 수 있습니다. 테스트 및 개발 벤치의 경우 Clear/Soft 상태가 허용될 수 있습니다. 호스트의 RAM이 MinFree의 64% 미만이면 호스트에서 실행 중인 VM에 성능 문제가 있음이 분명합니다.

각 상태에서 VM의 성능에 실질적으로 영향을 미치지 않는 TPS에서 시작하여 스와핑으로 끝나는 특정 메모리 회수 기술이 적용됩니다. 나는 그들에 대해 더 말할 것입니다.

투명한 페이지 공유(TPS). 대략적으로 말하면 TPS는 서버에서 가상 시스템 메모리 페이지의 중복 제거입니다.

ESXi는 페이지의 해시 합계를 세고 비교하여 가상 시스템 RAM의 동일한 페이지를 찾고 중복 페이지를 제거하여 서버의 물리적 메모리에서 동일한 페이지에 대한 링크로 바꿉니다. 결과적으로 물리적 메모리 소비가 줄어들고 성능 저하가 거의 또는 전혀 없이 일부 메모리 초과 할당이 달성될 수 있습니다.

출처

이 메커니즘은 4KB 메모리 페이지(작은 페이지)에서만 작동합니다. 하이퍼바이저는 2MB(큰 페이지)의 페이지를 중복 제거하려고 시도조차 하지 않습니다. 이 크기의 동일한 페이지를 찾을 기회는 많지 않습니다.

기본적으로 ESXi는 대용량 페이지에 메모리를 할당합니다. 큰 페이지를 작은 페이지로 나누기는 높음 상태 임계값에 도달하면 시작되고 지우기 상태에 도달하면 강제 실행됩니다(하이퍼바이저 상태 표 참조).

호스트 RAM이 가득 찰 때까지 기다리지 않고 TPS가 작동하도록 하려면 고급 옵션 ESXi에서 값을 설정해야 합니다. "Mem.AllocGuestLargePage" 0으로 설정합니다(기본값 1). 그러면 가상 머신에 대한 대용량 메모리 페이지 할당이 비활성화됩니다.

2014년 XNUMX월부터 ESXi의 모든 릴리스에서 이론적으로 한 VM에서 다른 VM의 RAM으로의 액세스를 허용하는 취약점이 발견되어 VM 간 TPS가 기본적으로 비활성화되었습니다. 자세한 내용은 여기를 참조하십시오. TPS 취약점을 악용하는 실제 구현에 대한 정보를 접하지 못했습니다.

고급 옵션을 통해 제어되는 TPS 정책 "Mem.ShareForceSalting" ESXi에서:
0 - VM 간 TPS. TPS는 서로 다른 VM의 페이지에서 작동합니다.
1 – VMX에서 "sched.mem.pshare.salt" 값이 동일한 VM용 TPS
2(기본값) - VM 내부 TPS. TPS는 VM 내부의 페이지에서 작동합니다.

큰 페이지를 끄고 테스트 벤치에서 Inter-VM TPS를 켜는 것이 좋습니다. 동일한 유형의 VM이 다수 있는 스탠드에도 사용할 수 있습니다. 예를 들어, VDI가 있는 스탠드에서 물리적 메모리의 절약은 수십 퍼센트에 달할 수 있습니다.

메모리 벌루닝. Ballooning은 더 이상 VM 운영 체제에 TPS와 같은 무해하고 투명한 기술이 아닙니다. 하지만 적절하게 적용하면 Ballooning과 함께 생활하고 일할 수도 있습니다.

Vmware Tools와 함께 Balloon Driver(vmmemctl이라고도 함)라는 특수 드라이버가 VM에 설치됩니다. 하이퍼바이저의 물리적 메모리가 부족해지고 소프트 상태가 되면 ESXi는 이 Balloon Driver를 통해 사용되지 않은 RAM을 회수하도록 VM에 요청합니다. 드라이버는 차례로 운영 체제 수준에서 작동하고 여유 메모리를 요청합니다. 하이퍼바이저는 Balloon Driver가 점유한 물리적 메모리 페이지를 확인하고 가상 머신에서 메모리를 가져와 호스트로 반환합니다. OS 수준에서 Balloon Driver가 메모리를 차지하기 때문에 OS 작동에 문제가 없습니다. 기본적으로 Balloon Driver는 VM 메모리의 최대 65%를 차지할 수 있습니다.

VM에 VMware Tools가 설치되어 있지 않거나 Ballooning이 비활성화된 경우(권장하지는 않지만 KB:) 하이퍼바이저는 즉시 더 엄격한 메모리 제거 기술로 전환합니다. 결론: VMware 도구가 VM에 있는지 확인하십시오.

Balloon Driver의 동작은 VMware Tools를 통해 OS에서 확인 가능.

메모리 압축. 이 기술은 ESXi가 하드 상태에 도달했을 때 사용됩니다. 이름에서 알 수 있듯이 ESXi는 4KB RAM 페이지를 2KB로 축소하여 서버의 물리적 메모리 공간을 확보하려고 시도합니다. 이 기술은 페이지가 먼저 압축 해제되어야 하므로 VM RAM 페이지의 내용에 대한 액세스 시간을 상당히 증가시킵니다. 때로는 모든 페이지를 압축할 수 없으며 프로세스 자체에 시간이 걸립니다. 따라서 이 기술은 실제로는 그다지 효과적이지 않습니다.

메모리 스와핑. 짧은 메모리 압축 단계 후 ESXi는 거의 불가피하게(VM이 다른 호스트로 이동하지 않았거나 꺼지지 않은 경우) 스와핑으로 전환됩니다. 그리고 남은 메모리가 거의 없는 경우(낮은 상태) 하이퍼바이저도 VM에 대한 메모리 페이지 할당을 중지하므로 VM의 게스트 OS에 문제가 발생할 수 있습니다.

스와핑이 작동하는 방식은 다음과 같습니다. 가상 머신을 켜면 확장자가 .vswp인 파일이 생성됩니다. 크기는 VM의 예약되지 않은 RAM과 동일하며 구성된 메모리와 예약된 메모리의 차이입니다. 스와핑이 실행 중일 때 ESXi는 가상 시스템 메모리 페이지를 이 파일로 언로드하고 서버의 물리적 메모리 대신 작업을 시작합니다. 물론 이러한 "작동" 메모리는 .vswp가 빠른 스토리지에 있더라도 실제 메모리보다 몇 배 더 느립니다.

Ballooning과 달리 VM에서 사용하지 않는 페이지를 가져올 때 Swaping을 사용하면 OS 또는 VM 내부의 응용 프로그램에서 적극적으로 사용하는 페이지를 디스크로 이동할 수 있습니다. 결과적으로 VM의 성능은 정지 지점까지 떨어집니다. VM은 공식적으로 작동하며 최소한 OS에서 적절하게 비활성화할 수 있습니다. 참으면 😉

VM이 스왑으로 이동한 경우 이는 비정상적인 상황이며 가능하면 피하는 것이 가장 좋습니다.

주요 VM 메모리 성능 카운터

그래서 우리는 요점에 도달했습니다. VM의 메모리 상태를 모니터링하기 위해 다음 카운터가 있습니다.

최근활동 — VM이 이전 측정 기간에 액세스한 RAM의 양(KB)을 표시합니다.

용법 - 활성과 동일하지만 VM의 구성된 RAM의 백분율입니다. 다음 공식을 사용하여 계산: 활성 ÷ 가상 머신 구성 메모리 크기.
높은 사용량 및 활성이 각각 항상 VM 성능 문제를 나타내는 것은 아닙니다. VM이 적극적으로 메모리를 사용하는 경우(최소한 액세스 가능) 메모리가 충분하지 않다는 의미는 아닙니다. 오히려 OS에서 무슨 일이 일어나고 있는지 확인하는 기회입니다.
VM에 대한 표준 메모리 사용량 경보가 있습니다.

공유 - TPS를 사용하여 중복 제거된 VM RAM의 양(VM 내부 또는 VM 간).

부여 - VM에 제공된 물리적 호스트 메모리(KB)의 양입니다. 공유를 포함합니다.

소비 된 (Granted - Shared) - VM이 호스트에서 소비하는 물리적 메모리(KB)의 양입니다. 공유는 포함하지 않습니다.

VM 메모리의 일부가 호스트의 물리적 메모리가 아닌 스왑 파일에서 제공되거나 Balloon Driver를 통해 VM에서 메모리를 가져오는 경우 이 양은 Granted 및 Consumed에서 고려되지 않습니다.
High Granted 및 Consumed 값은 완전히 정상입니다. 운영 체제는 점차적으로 하이퍼바이저에서 메모리를 가져오고 반환하지 않습니다. 시간이 지남에 따라 능동적으로 실행되는 VM에서 이러한 카운터의 값은 구성된 메모리 양에 접근하고 그대로 유지됩니다.

제로 — XNUMX을 포함하는 VM RAM(KB)의 양입니다. 이러한 메모리는 하이퍼바이저에서 사용 가능한 것으로 간주되며 다른 가상 머신에 제공될 수 있습니다. 게스트 OS가 제로 메모리에 무언가를 쓴 후에는 Consumed 상태로 전환되고 다시 반환되지 않습니다.

예약된 오버헤드 — VM 작업을 위해 하이퍼바이저에서 예약한 VM RAM의 양(KB)입니다. 적은 양이지만 호스트에서 사용할 수 있어야 합니다. 그렇지 않으면 VM이 시작되지 않습니다.

풍선 — Balloon Driver를 사용하여 VM에서 점유한 RAM(KB)의 양입니다.

압축 - 압축된 RAM의 양(KB).

스왑 - 서버의 실제 메모리 부족으로 인해 디스크로 이동한 RAM의 양(KB)입니다.
벌룬 및 기타 메모리 회수 기술 카운터는 XNUMX입니다.

150GB RAM이 있는 정상적으로 작동하는 VM에 대한 메모리 카운터가 포함된 그래프는 다음과 같습니다.

아래 그래프에서 VM에는 명백한 문제가 있습니다. 그래프 아래에서 이 VM에 대해 설명된 모든 RAM 작업 기술이 사용되었음을 알 수 있습니다. 이 VM의 Balloon은 Consumed보다 훨씬 큽니다. 실제로 VM은 살아있는 것보다 죽은 것입니다.

ESXTOP

CPU와 마찬가지로 호스트의 상황과 최대 2초 간격의 역학을 신속하게 평가하려면 ESXTOP을 사용해야 합니다.

메모리의 ESXTOP 화면은 "m" 키로 호출되며 다음과 같습니다(필드 B, D, H, J, K, L, O가 선택됨).

다음 매개 변수가 관심을 가질 것입니다.

메모리 오버커밋 평균 - 1분, 5분 및 15분 동안 호스트의 평균 메모리 초과 할당 값입니다. XNUMX보다 크면 무슨 일이 일어나고 있는지 확인할 수 있지만 항상 문제의 지표는 아닙니다.

인라인 PMEM/MB и VMKMEM/MB - 서버의 물리적 메모리 및 VMkernel에서 사용 가능한 메모리에 대한 정보. 흥미로운 여기에서 minfree 값(MB), 메모리의 호스트 상태(이 경우 높음)를 볼 수 있습니다.

인라인 NUMA/MB NUMA 노드(소켓)별 RAM 분포를 확인할 수 있습니다. 이 예에서는 분포가 고르지 않아 원칙적으로 그다지 좋지 않습니다.

다음은 메모리 회수 기술에 대한 일반적인 서버 통계입니다.

PSHARE/MB TPS 통계입니다.

스왑/MB — 스왑 사용 통계;

우편번호/MB — 메모리 페이지 압축 통계;

MEMCTL/MB — 풍선 드라이버 사용 통계.

개별 VM의 경우 다음 정보에 관심이 있을 수 있습니다. 청중을 혼동하지 않도록 VM 이름을 숨겼습니다 :). ESXTOP 메트릭이 vSphere의 카운터와 유사하면 해당 카운터를 제공합니다.

MEMSZ — VM에 구성된 메모리 양(MB).
MEMSZ = GRANT + MCTLSZ + SWCUR + 변경되지 않음.

GRANT — MB에게 부여됨.

TCHD — MB 단위로 활성화됩니다.

MCTL? - 벌룬 드라이버가 VM에 설치되어 있는지 여부.

MCTLSZ — 풍선을 MB로.

MCTLGT — ESXi가 Balloon Driver(Memctl Target)를 통해 VM에서 가져오려는 RAM(MB)의 양입니다.

엠씨엘맥스 - ESXi가 Balloon Driver를 통해 VM에서 가져올 수 있는 최대 RAM 양(MB).

SWCUR — 스왑 파일에서 VM에 할당된 현재 RAM 양(MB)입니다.

SWG.T. - ESXi가 스왑 파일(스왑 대상)에서 VM에 제공하려는 RAM(MB)의 양입니다.

또한 ESXTOP을 통해 VM의 NUMA 토폴로지에 대한 보다 자세한 정보를 확인할 수 있습니다. 이렇게 하려면 D, G 필드를 선택합니다.

작은 – VM이 있는 NUMA 노드. 여기에서 하나의 NUMA 노드에 맞지 않는 넓은 vm을 즉시 확인할 수 있습니다.

NRMEM - VM이 원격 NUMA 노드에서 차지하는 메모리의 메가바이트 수.

NLMEM - VM이 로컬 NUMA 노드에서 차지하는 메모리의 메가바이트 수.

N%L – 로컬 NUMA 노드의 VM 메모리 비율(80% 미만인 경우 성능 문제가 발생할 수 있음).

하이퍼바이저의 메모리

일반적으로 하이퍼바이저의 CPU 카운터가 특별히 중요하지 않은 경우 상황은 메모리와 반대입니다. VM의 높은 메모리 사용량이 항상 성능 문제를 나타내는 것은 아니지만 하이퍼바이저의 높은 메모리 사용량은 메모리 관리 기술을 트리거하고 VM에서 성능 문제를 일으킵니다. VM이 스왑에 들어가는 것을 방지하려면 호스트 메모리 사용량 경보를 모니터링해야 합니다.

스왑 해제

VM이 스왑 상태이면 성능이 크게 저하됩니다. 호스트에 여유 RAM이 나타난 후 벌루닝 및 압축의 흔적은 빠르게 사라지지만 가상 머신은 서두르지 않고 Swap에서 서버 RAM으로 돌아갑니다.
ESXi 6.0 이전에는 스왑에서 VM을 가져오는 안정적이고 빠른 유일한 방법은 재부팅하는 것이었습니다(더 정확하게는 컨테이너를 껐다 켜는 것). ESXi 6.0부터 공식적인 것은 아니지만 Swap에서 VM을 제거하는 작동하고 안정적인 방법이 등장했습니다. 한 회의에서 CPU 스케줄러를 담당하는 VMware 엔지니어 중 한 명과 이야기를 나눌 수 있었습니다. 그는 이 방법이 매우 효과적이고 안전하다는 것을 확인했습니다. 경험상 문제가 없었습니다.

스왑에서 VM을 제거하기 위한 실제 명령 기술 된 던컨 에핑. 자세한 설명을 반복하지 않고 사용 예를 들어 보겠습니다. 스크린샷에서 볼 수 있듯이 지정된 명령을 실행하고 얼마 후 VM에서 Swap이 사라집니다.

ESXi 메모리 관리 팁

마지막으로 RAM으로 인한 VM 성능 문제를 방지하는 데 도움이 되는 몇 가지 팁이 있습니다.

• 생산 클러스터에서 메모리 초과 할당을 방지합니다. DRS(및 관리자)가 조작할 공간을 확보하고 VM이 마이그레이션 중에 스왑으로 전환되지 않도록 클러스터에 항상 ~20-30%의 여유 메모리를 두는 것이 좋습니다. 또한 내결함성 여유를 잊지 마십시오. 하나의 서버가 실패하고 VM이 HA를 사용하여 재부팅되면 일부 시스템도 Swap으로 전환되는 것은 불쾌합니다.
• 고도로 통합된 인프라에서 호스트 메모리의 절반 이상으로 VM을 생성하지 마십시오. 이렇게 하면 DRS가 문제 없이 클러스터 서버 전체에 가상 머신을 배포하는 데 다시 도움이 됩니다. 물론 이 규칙은 보편적이지 않습니다 :).
• 호스트 메모리 사용량 알람을 확인하십시오.
• VM에 VMware 도구를 설치하는 것을 잊지 말고 Ballooning을 끄지 마십시오.
• VDI 및 테스트 환경에서 Inter-VM TPS를 활성화하고 Large Pages를 비활성화하는 것을 고려하십시오.
• VM에 성능 문제가 있는 경우 원격 NUMA 노드의 메모리를 사용하고 있는지 확인하십시오.
• 가능한 한 빨리 스왑에서 VM을 제거하십시오! 무엇보다도 VM이 스왑에 있으면 명백한 이유로 스토리지 시스템에 문제가 발생합니다.

RAM에 관한 모든 것입니다. 아래는 세부 사항을 파헤치고 싶은 사람들을 위한 관련 기사입니다. 다음 기사는 storadzh에 관한 것입니다.

유용한 링크http://www.yellow-bricks.com/2015/03/02/what-happens-at-which-vsphere-memory-state/
http://www.yellow-bricks.com/2013/06/14/how-does-mem-minfreepct-work-with-vsphere-5-0-and-up/
https://www.vladan.fr/vmware-transparent-page-sharing-tps-explained/
http://www.yellow-bricks.com/2016/06/02/memory-pages-swapped-can-unswap/
https://kb.vmware.com/s/article/1002586
https://www.vladan.fr/what-is-vmware-memory-ballooning/
https://kb.vmware.com/s/article/2080735
https://kb.vmware.com/s/article/2017642
https://labs.vmware.com/vmtj/vmware-esx-memory-resource-management-swap
https://blogs.vmware.com/vsphere/2013/10/understanding-vsphere-active-memory.html
https://www.vmware.com/support/developer/converter-sdk/conv51_apireference/memory_counters.html
https://docs.vmware.com/en/VMware-vSphere/6.5/vsphere-esxi-vcenter-server-65-monitoring-performance-guide.pdf

출처 : habr.com