VMware vSphere의 가상 머신 성능 분석. 1부: CPU

VMware vSphere(또는 기타 기술 스택)를 기반으로 가상 인프라를 관리하는 경우 사용자로부터 "가상 머신이 느리다!"라는 불만을 자주 듣게 될 것입니다. 이 기사 시리즈에서는 성능 지표를 분석하고 속도가 느려지는 이유와 원인, 그리고 속도가 느려지지 않는지 확인하는 방법을 알려 드리겠습니다.

가상 머신 성능의 다음 측면을 고려하겠습니다.

• CPU,
• 램,
• 디스크,
• 회로망.

CPU부터 시작하겠습니다.

성능을 분석하려면 다음이 필요합니다.

• vCenter 성능 카운터 – vSphere Client를 통해 그래프를 볼 수 있는 성능 카운터. 이러한 카운터에 대한 정보는 클라이언트의 모든 버전(C#의 "thick" 클라이언트, Flex의 웹 클라이언트, HTML5의 웹 클라이언트)에서 사용할 수 있습니다. 이 기사에서는 C# 클라이언트의 스크린샷을 사용하겠습니다. 왜냐하면 축소형이 더 보기 좋기 때문입니다. :)
• ESXTOP – ESXi 명령줄에서 실행되는 유틸리티입니다. 이를 통해 실시간으로 성능 카운터 값을 얻거나 추가 분석을 위해 특정 기간 동안 이러한 값을 .csv 파일에 업로드할 수 있습니다. 다음으로 이 도구에 대해 자세히 설명하고 해당 주제에 대한 문서 및 기사에 대한 몇 가지 유용한 링크를 제공하겠습니다.

약간의 이론

ESXi에서는 VMware 용어로 별도의 프로세스가 각 vCPU(가상 머신 코어)의 작동을 담당합니다. 서비스 프로세스도 있지만 VM 성능 분석 관점에서는 그다지 흥미롭지 않습니다.

ESXi의 프로세스는 다음 네 가지 상태 중 하나일 수 있습니다.

• 달리기 – 프로세스가 몇 가지 유용한 작업을 수행합니다.
• 기다림 – 프로세스가 어떤 작업도 수행하지 않고(유휴) 있거나 입력/출력을 기다리고 있습니다.
• 코스탑 – 멀티 코어 가상 머신에서 발생하는 조건입니다. 이는 하이퍼바이저 CPU 스케줄러(ESXi CPU 스케줄러)가 물리적 서버 코어에서 모든 활성 가상 머신 코어의 동시 실행을 예약할 수 없는 경우 발생합니다. 실제 세계에서는 모든 프로세서 코어가 병렬로 작동하고 VM 내부의 게스트 OS는 유사한 동작을 기대하므로 하이퍼바이저는 클록 주기를 더 빨리 완료할 수 있는 VM 코어의 속도를 줄여야 합니다. 최신 버전의 ESXi에서 CPU 스케줄러는 완화된 공동 스케줄링이라는 메커니즘을 사용합니다. 즉, 하이퍼바이저는 "가장 빠른" 가상 머신 코어와 "가장 느린" 가상 머신 코어 간의 차이(기울기)를 고려합니다. 간격이 특정 임계값을 초과하면 고속 코어가 코스트오프 상태로 들어갑니다. VM 코어가 이 상태에서 많은 시간을 소비하면 성능 문제가 발생할 수 있습니다.
• 준비 – 하이퍼바이저가 실행을 위해 리소스를 할당할 수 없는 경우 프로세스는 이 상태로 들어갑니다. 준비 값이 높으면 VM 성능 문제가 발생할 수 있습니다.

기본 가상 머신 CPU 성능 카운터

CPU 사용량, %. 특정 기간 동안의 CPU 사용량을 백분율로 표시합니다.

분석하는 방법? VM이 지속적으로 CPU를 90%로 사용하거나 최대 100%에 도달하는 경우 문제가 있는 것입니다. 문제는 VM 내부 애플리케이션의 "느린" 작동뿐만 아니라 네트워크를 통한 VM 액세스 불가능으로도 표현될 수 있습니다. 모니터링 시스템에서 VM이 주기적으로 저하되는 것으로 표시되면 CPU 사용량 그래프의 최고점에 주의하세요.

가상 머신의 CPU 로드를 표시하는 표준 경보가 있습니다.

무엇을해야 하는가? VM의 CPU 사용량이 지속적으로 급증하는 경우 vCPU 수를 늘리거나(불행히도 이것이 항상 도움이 되는 것은 아님) VM을 더 강력한 프로세서가 있는 서버로 이동하는 것을 고려해 볼 수 있습니다.

CPU 사용량(MHz)

vCenter 사용량(%) 그래프에서는 전체 가상 머신에 대해서만 볼 수 있으며 개별 코어에 대한 그래프는 없습니다(Esxtop에는 코어에 대한 % 값이 있음). 각 코어에 대해 사용량(MHz)을 볼 수 있습니다.

분석하는 방법? 애플리케이션이 멀티 코어 아키텍처에 최적화되지 않은 경우가 있습니다. 즉, 하나의 코어만 100% 사용하고 나머지는 로드 없이 유휴 상태입니다. 예를 들어, 기본 백업 설정을 사용하면 MS SQL은 하나의 코어에서만 프로세스를 시작합니다. 결과적으로 백업 속도가 느려지는 것은 디스크의 느린 속도(사용자가 처음에 불만을 제기한 이유) 때문이 아니라 프로세서가 대처할 수 없기 때문입니다. 매개변수를 변경하여 문제가 해결되었습니다. 백업이 여러 파일에서(각각 여러 프로세스에서) 병렬로 실행되기 시작했습니다.

코어의 고르지 않은 부하의 예입니다.

또한 (위 그래프에서와 같이) 코어가 고르지 않게 로드되고 일부 코어의 피크가 100%인 상황도 있습니다. 하나의 코어만 로드하는 경우 CPU 사용량에 대한 경보는 작동하지 않지만(전체 VM에 대해) 성능 문제가 발생합니다.

무엇을해야 하는가? 가상 머신의 소프트웨어가 코어를 고르지 않게 로드하는 경우(코어 하나 또는 코어의 일부만 사용) 코어 수를 늘려도 소용이 없습니다. 이 경우 VM을 더 강력한 프로세서가 있는 서버로 이동하는 것이 좋습니다.

서버 BIOS에서 전력 소비 설정을 확인해 볼 수도 있습니다. 많은 관리자는 BIOS에서 고성능 모드를 활성화하여 C 상태 및 P 상태 에너지 절약 기술을 비활성화합니다. 최신 Intel 프로세서는 다른 코어를 희생하여 개별 프로세서 코어의 주파수를 높이는 Turbo Boost 기술을 사용합니다. 하지만 에너지 절약 기술이 켜져 있을 때만 작동합니다. 이를 비활성화하면 프로세서는 로드되지 않은 코어의 전력 소비를 줄일 수 없습니다.

VMware에서는 서버의 절전 기술을 비활성화하지 않고 가능한 한 하이퍼바이저에 전원 관리를 맡기는 모드를 선택할 것을 권장합니다. 이 경우 하이퍼바이저 전력 소비 설정에서 고성능을 선택해야 합니다.

인프라에 증가된 CPU 주파수가 필요한 개별 VM(또는 VM 코어)이 있는 경우 전력 소비를 올바르게 조정하면 성능이 크게 향상될 수 있습니다.

CPU 준비

VM Core(vCPU)가 준비 상태이면 유용한 작업을 수행하지 않습니다. 이 조건은 하이퍼바이저가 가상 머신의 vCPU 프로세스를 할당할 수 있는 여유 물리적 코어를 찾지 못할 때 발생합니다.

분석하는 방법? 일반적으로 가상 머신의 코어가 10% 이상 준비 상태인 경우 성능 문제가 발생합니다. 간단히 말해서, VM이 물리적 리소스를 사용할 수 있을 때까지 기다리는 시간이 10% 이상입니다.

vCenter에서는 CPU Ready와 관련된 2개의 카운터를 볼 수 있습니다.

• 준비,
• 준비된.

두 카운터의 값은 전체 VM과 개별 코어 모두에 대해 볼 수 있습니다.
준비 상태는 값을 즉시 백분율로 표시하지만 실시간으로만 표시됩니다(지난 20시간 동안의 데이터, 측정 간격 XNUMX초). "긴급" 문제를 검색할 때만 이 카운터를 사용하는 것이 좋습니다.

준비된 카운터 값은 역사적인 관점에서도 볼 수 있습니다. 이는 패턴을 설정하고 문제를 심층적으로 분석하는 데 유용합니다. 예를 들어 특정 시점에 가상 머신에서 성능 문제가 발생하기 시작하면 CPU Ready 값의 간격을 이 VM이 실행 중인 서버의 총 로드와 비교하여 로드를 줄이기 위한 조치를 취할 수 있습니다(DRS가 있는 경우). 실패).

준비는 준비 상태와 달리 백분율이 아닌 밀리초 단위로 표시됩니다. 이는 요약 유형 카운터입니다. 즉, 측정 기간 동안 VM 코어가 준비 상태에 있었던 기간을 표시합니다. 간단한 공식을 사용하여 이 값을 백분율로 변환할 수 있습니다.

(CPU 준비 합계 값 / (차트 기본 업데이트 간격(초) * 1000)) * 100 = CPU 준비 %

예를 들어 아래 그래프에 있는 VM의 경우 전체 가상 머신에 대한 최대 준비 값은 다음과 같습니다.

준비 비율을 계산할 때 다음 두 가지 사항에 주의해야 합니다.

• 전체 VM의 준비 값은 코어 전체의 준비 합계입니다.
• 측정 간격. 실시간의 경우 20초이고, 예를 들어 일일 차트의 경우 300초입니다.

적극적인 문제 해결을 사용하면 이러한 간단한 사항을 쉽게 놓칠 수 있으며 존재하지 않는 문제를 해결하는 데 귀중한 시간을 낭비할 수 있습니다.

아래 그래프의 데이터를 바탕으로 Ready를 계산해 보겠습니다. (324474/(20*1000))*100 = 전체 VM의 경우 1622%입니다. 코어를 보면 그다지 무섭지 않습니다 : 1622/64 = 코어당 25%. 이 경우 캐치를 발견하기가 매우 쉽습니다. Ready 값은 비현실적입니다. 그러나 여러 코어가 있는 전체 VM에 대해 약 10~20%를 이야기한다면 각 코어의 값은 정상 범위 내에 있을 수 있습니다.

무엇을해야 하는가? 준비 값이 높으면 가상 머신의 정상적인 작동을 위한 프로세서 리소스가 서버에 충분하지 않음을 나타냅니다. 이러한 상황에서 남은 것은 프로세서(vCPU:pCPU)에 의한 초과 구독을 줄이는 것뿐입니다. 분명히 이는 기존 VM의 매개변수를 줄이거나 VM의 일부를 다른 서버로 마이그레이션하여 달성할 수 있습니다.

공동 정지

분석하는 방법? 이 카운터도 합계 유형이며 Ready와 같은 방식으로 백분율로 변환됩니다.

(CPU 공동 중지 합계 값 / (차트 기본 업데이트 간격(초) * 1000)) * 100 = CPU 공동 중지 %

여기에서는 VM의 코어 수와 측정 간격에도 주의를 기울여야 합니다.
Costop 상태에서는 커널이 유용한 작업을 수행하지 않습니다. VM 크기와 서버의 일반 로드를 올바르게 선택하면 동시 중지 카운터는 XNUMX에 가까워야 합니다.

이 경우에는 부하가 확실히 비정상입니다 :)

무엇을해야 하는가? 다수의 코어가 있는 여러 VM이 하나의 하이퍼바이저에서 실행되고 있고 CPU에 초과 구독이 있는 경우 공동 중지 카운터가 증가할 수 있으며, 이로 인해 이러한 VM의 성능에 문제가 발생할 수 있습니다.

또한 한 VM의 활성 코어가 하이퍼트레딩이 활성화된 한 물리적 서버 코어의 스레드를 사용하는 경우 공동 중지가 증가합니다. 예를 들어 VM에 실행 중인 서버에서 물리적으로 사용 가능한 것보다 더 많은 코어가 있거나 VM에 대해 "preferHT" 설정이 활성화된 경우 이러한 상황이 발생할 수 있습니다. 이 설정에 대해 읽을 수 있습니다. 여기에.

높은 공동 중지로 인한 VM 성능 문제를 방지하려면 이 VM에서 실행되는 소프트웨어 제조업체의 권장 사항과 VM이 실행되는 물리적 서버의 기능에 따라 VM 크기를 선택하십시오.

예비 코어를 추가하지 마십시오. 이렇게 하면 VM 자체뿐만 아니라 서버의 인접 항목에도 성능 문제가 발생할 수 있습니다.

기타 유용한 CPU 지표

달리기 – 측정 기간 동안 vCPU가 RUN 상태, 즉 실제로 유용한 작업을 수행한 시간(ms)입니다.

유휴 – 측정 기간 동안 vCPU가 비활성 상태였던 시간(ms)입니다. 높은 Idle 값은 문제가 되지 않습니다. vCPU는 "아무것도 할 수 없습니다".

기다림 – 측정 기간 동안 vCPU가 대기 상태에 있었던 시간(ms)입니다. 이 카운터에는 IDLE이 포함되어 있으므로 대기 값이 높다고 해서 문제가 발생하는 것은 아닙니다. 그러나 Wait가 높을 때 Wait IDLE이 낮다면 이는 VM이 ​​I/O 작업이 완료되기를 기다리고 있다는 의미이며, 이는 결국 하드 드라이브 또는 VM의 가상 장치 성능에 문제가 있음을 나타낼 수 있습니다.

최대 제한 – 측정 기간 동안 설정된 리소스 제한으로 인해 vCPU가 준비 상태에 있었던 시간(ms)입니다. 성능이 설명할 수 없을 정도로 낮은 경우 VM 설정에서 이 카운터 값과 CPU 제한을 확인하는 것이 유용합니다. VM에는 실제로 사용자가 인식하지 못하는 제한이 있을 수 있습니다. 예를 들어 CPU 제한이 설정된 템플릿에서 VM을 복제한 경우에 이런 일이 발생합니다.

스왑 대기 – 측정 기간 동안 vCPU가 VMkernel Swap 작업을 기다린 시간입니다. 이 카운터의 값이 XNUMX보다 크면 VM에 확실히 성능 문제가 있는 것입니다. RAM 카운터에 관한 기사에서 SWAP에 대해 자세히 설명하겠습니다.

ESXTOP

vCenter의 성능 카운터가 기록 데이터 분석에 적합하다면 문제에 대한 운영 분석은 ESXTOP에서 더 잘 수행됩니다. 여기에서는 모든 값이 미리 만들어진 형태로 제공되며(아무것도 번역할 필요 없음), 최소 측정 기간은 2초입니다.
CPU에 대한 ESXTOP 화면은 "c" 키로 호출되며 다음과 같습니다.

편의상 Shift-V를 눌러 가상 머신 프로세스만 남길 수 있습니다.
개별 VM 코어에 대한 지표를 보려면 "e"를 누르고 관심 있는 VM의 GID를 입력합니다(아래 스크린샷에서는 30919).

기본적으로 제공되는 열을 간략하게 살펴보겠습니다. "f"를 누르면 추가 열을 추가할 수 있습니다.

NWLD(세계 수) – 그룹의 프로세스 수. 그룹을 확장하고 각 프로세스(예: 멀티 코어 VM의 각 코어)에 대한 측정항목을 보려면 "e"를 누릅니다. 그룹에 둘 이상의 프로세스가 있는 경우 그룹의 메트릭 값은 개별 프로세스의 메트릭 합계와 같습니다.

%사용된 – 프로세스 또는 프로세스 그룹에서 사용되는 서버 CPU주기 수.

%달리다 – 측정 기간 동안 프로세스가 RUN 상태에 있었던 시간, 즉 유용한 일을 했습니다. 하이퍼스레딩, 빈도 스케일링 및 시스템 작업(%SYS)에 소요된 시간을 고려하지 않는다는 점에서 %USED와 다릅니다.

%SYS – 시스템 작업(예: 인터럽트 처리, I/O, 네트워크 작업 등)에 소요된 시간. VM에 대규모 I/O가 있는 경우 값이 높을 수 있습니다.

%OVRLP – VM 프로세스가 실행 중인 물리적 코어가 다른 프로세스의 작업에 소비한 시간입니다.

이러한 측정항목은 다음과 같이 서로 관련됩니다.

%사용됨 = %RUN + %SYS - %OVRLP.

일반적으로 %USED 측정항목이 더 많은 정보를 제공합니다.

%기다리다 – 측정 기간 동안 프로세스가 대기 상태에 있었던 시간. IDLE을 활성화합니다.

%게으른 – 측정 기간 동안 프로세스가 IDLE 상태에 있었던 기간.

%SWPWT – 측정 기간 동안 vCPU가 VMkernel Swap 작업을 기다린 시간입니다.

%VMWAIT – 측정 기간 동안 vCPU가 이벤트(일반적으로 I/O)를 기다리는 상태에 있었던 기간입니다. vCenter에는 유사한 카운터가 없습니다. 값이 높으면 VM의 I/O에 문제가 있음을 나타냅니다.

%WAIT = %VMWAIT + %IDLE + %SWPWT.

VM이 VMkernel Swap을 사용하지 않는 경우 성능 문제를 분석할 때 %VMWAIT를 살펴보는 것이 좋습니다. 이 지표는 VM이 ​​아무 작업도 수행하지 않은 시간(%IDLE)을 고려하지 않기 때문입니다.

%RDY – 측정 기간 동안 프로세스가 준비 상태에 있었던 기간입니다.

%CSTP – 측정 기간 동안 프로세스가 코스탑 상태에 있었던 기간.

%MLMTD – 측정 기간 동안 설정된 리소스 제한으로 인해 vCPU가 준비 상태에 있었던 기간입니다.

%WAIT + %RDY + %CSTP + %RUN = 100% – VM 코어는 항상 이 네 가지 상태 중 하나입니다.

하이퍼바이저의 CPU

vCenter에는 하이퍼바이저에 대한 CPU 성능 카운터도 있지만 그다지 흥미롭지는 않습니다. 이는 단순히 서버에 있는 모든 VM에 대한 카운터의 합계일 뿐입니다.
서버의 CPU 상태를 보는 가장 편리한 방법은 요약 탭을 이용하는 것입니다.

서버와 가상 머신의 경우 표준 경보가 있습니다.

서버 CPU 로드가 높으면 해당 서버에서 실행되는 VM에 성능 문제가 발생하기 시작합니다.

ESXTOP에서는 서버 CPU 로드 데이터가 화면 상단에 표시됩니다. 하이퍼바이저에 그다지 유익하지 않은 표준 CPU 로드 외에도 세 가지 측정항목이 더 있습니다.

핵심 활용도(%) – 물리적 서버 코어를 로드합니다. 이 카운터는 측정 기간 동안 코어가 작업을 수행한 시간을 보여줍니다.

PCPU 활용도(%) – 하이퍼스레딩이 활성화된 경우 물리적 코어당 XNUMX개의 스레드(PCPU)가 있습니다. 이 지표는 각 스레드가 작업을 완료하는 데 걸린 시간을 보여줍니다.

사용된 PCPU(%) – PCPU UTIL(%)과 동일하지만 주파수 스케일링(에너지 절약을 위해 코어 주파수를 줄이거나 Turbo Boost 기술로 인해 코어 주파수를 높임) 및 하이퍼스레딩을 고려합니다.

PCPU_USED% = PCPU_UTIL% * 유효 코어 주파수 / 공칭 코어 주파수.

이 스크린샷에서 일부 코어의 경우 Turbo Boost로 인해 코어 주파수가 공칭 주파수보다 높기 때문에 USED 값이 100%보다 큽니다.

하이퍼스레딩을 고려하는 방법에 대한 몇 마디입니다. 프로세스가 서버 물리적 코어의 두 스레드 모두에서 100% 실행되고 코어가 정격 빈도로 작동하는 경우:

• 코어의 CORE UTIL은 100%입니다.
• 두 스레드 모두에 대한 PCPU UTIL은 100%입니다.
• 두 스레드 모두에 사용된 PCPU는 50%입니다.

측정 기간 동안 두 스레드가 모두 100% 작동하지 않은 경우 스레드가 병렬로 작동한 기간 동안 코어에 사용된 PCPU는 절반으로 나뉩니다.

ESXTOP에는 서버 CPU 전력 소비 매개변수가 포함된 화면도 있습니다. 여기서는 서버가 에너지 절약 기술(C-상태 및 P-상태)을 사용하는지 여부를 확인할 수 있습니다. "p" 키로 호출됩니다:

일반적인 CPU 성능 문제

마지막으로 VM CPU 성능 문제의 일반적인 원인을 살펴보고 이를 해결하기 위한 간단한 팁을 제공하겠습니다.

코어 클럭 속도가 충분하지 않습니다. VM을 더 강력한 코어로 업그레이드할 수 없는 경우 전원 설정을 변경하여 Turbo Boost가 더 효율적으로 작동하도록 시도해 볼 수 있습니다.

VM 크기가 잘못되었습니다(코어가 너무 많거나 적음). 몇 개의 코어를 설치하면 VM에 CPU 로드가 높아집니다. 많으면 높은 코스톱을 잡아라.

서버의 CPU 초과 구독. VM의 준비 상태가 높으면 CPU 초과 구독을 줄입니다.

대규모 VM의 NUMA 토폴로지가 잘못되었습니다. VM(vNUMA)에 표시되는 NUMA 토폴로지는 서버(pNUMA)의 NUMA 토폴로지와 일치해야 합니다. 이 문제에 대한 진단 및 가능한 해결책은 예를 들어 책에 기록되어 있습니다. "VMware vSphere 6.5 호스트 리소스 심층 분석". 더 깊이 들어가고 싶지 않고 VM에 설치된 OS에 대한 라이센스 제한이 없다면 VM에 한 번에 하나의 코어씩 많은 가상 소켓을 만드십시오. 많이 잃지 않을 거예요 :)

이것이 CPU에 관한 전부입니다. 질문. 다음 편에서는 RAM에 대해 이야기하겠습니다.

유용한 링크http://virtual-red-dot.info/vm-cpu-counters-vsphere/
https://kb.vmware.com/kb/1017926
http://www.yellow-bricks.com/2012/07/17/why-is-wait-so-high/
https://communities.vmware.com/docs/DOC-9279
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/whats-new-vsphere65-perf.pdf
https://pages.rubrik.com/host-resources-deep-dive_request.html

출처 : habr.com