VMware에서 얼마나 많은 경합이 있습니까?

한동안 나는 지금 우리의 비즈니스 크리티컬 시스템 중 일부가 왜 온화함에서 극한까지 "느림"에 대한 보고서를 받고 있는지 알아 내려고 노력했습니다. 최근에 문제의 모든 서버가 호스팅되는 VMware 환경으로 눈을 돌 렸습니다.

최근에 SCOM 2012 용 Veeam VMware 관리 팩의 평가판을 다운로드하여 설치했지만보고 한 숫자를보고있는 데 어려움을 겪고 있습니다. 상사에게 알려주는 숫자가 사실임을 설득하기 위해 결과를 확인하기 위해 VMware 클라이언트 자체를 조사하기 시작했습니다.

이 VMware KB 기사를 보았습니다 . Co-Stop의 정의를 위해 구체적으로 다음과 같이 정의됩니다.

MP 가상 머신을 실행할 준비가 된 시간이지만 co-vCPU 스케줄링 경합으로 인해 지연이 발생했습니다.

내가 번역하는 것

게스트 OS는 호스트에서 시간이 필요하지만 리소스를 사용할 수있을 때까지 기다려야하므로 "응답 없음"으로 간주 될 수 있습니다.

이 번역이 정확합니까?

그렇다면 여기에 내가보고있는 내용을 알기 어려운 곳이 있습니다. "느린"VM의 대부분을 포함하는 호스트는 현재 CPU Co-stop 평균 127,835.94 밀리 초 를 보여 줍니다!

이것은 평균적으로이 호스트의 VM이 CPU 시간 동안 2 분 이상 기다려야한다는 것을 의미합니까 ???

이 호스트에는 2 개의 4 코어 CPU가 있으며 1x8 CPU 게스트와 14x4 CPU 게스트가 있습니다.

이 분야에서 경험 한 것들 중 일부를 설명 할 수 있습니다 ...

VMware가 고객 ( 또는 관리자 )에게 모범 사례에 대해 교육하는 적절한 작업을 수행하거나 제품이 발전함에 따라 이전의 모범 사례를 업데이트 한다고 믿지 않습니다 . 이 질문은 vCPU 할당과 같은 핵심 개념을 완전히 이해하지 못한 예입니다. 가장 좋은 방법은 VM에 더 많은 것이 필요할 때까지 단일 vCPU를 사용하여 소규모로 시작하는 것입니다.

OP의 경우 ESXi 호스트 서버에는 2 개의 쿼드 코어 CPU가 있으며 8 개의 물리적 코어를 생성합니다.

설명되는 가상 머신 레이아웃은 총 15 명입니다. 1 x 8 vCPU 및 14 x 4 vCPU 시스템. 특히 8 개의 vCPU 가있는 단일 게스트가 있는 경우 너무 커밋되었습니다 . 그것은 말도 안돼. 큰 VM이 필요한 경우 더 큰 서버가 필요할 수 있습니다.

가상 머신의 크기 를 올바르게 조정 하십시오. 나는 그들 중 대부분이 2 vCPU로 살 수 있다고 확신합니다. 가상 CPU를 추가해도 작업 속도가 빨라지지 않으므로 성능 문제에 대한 해결책이라면 잘못된 접근 방식입니다.

대부분의 환경에서 RAM은 가장 제한적인 리소스입니다. 그러나 경합이 너무 많으면 CPU가 문제가 될 수 있습니다. 이것에 대한 증거가 있습니다. 개별 VM에 너무 많은 용량 이 할당 된 경우 RAM도 문제가 될 수 있습니다 .

이것을 모니터링 할 수 있습니다. 찾고있는 측정 항목은 "CPU Ready %"입니다. 당신은 VM을 선택하고 이동하여은 vSphere 클라이언트에서이 액세스 할 수 있습니다 Performance> Overview> CPU 그래프.

• 5 % 미만 CPU 준비 -괜찮습니다.
• 5-10 % CPU 준비 -활동을 자세히 살펴보십시오.
• 10 % 이상 CPU 준비 -양호하지 않습니다.

아래 그래프에서 노란색 선을 주목하십시오.

문제가있는 가상 머신에서이를 확인하고 다시보고 하시겠습니까?

의견에 이중 쿼드 코어 ESXi 호스트가 있으며 하나의 8vCPU VM과 14 개의 4vCPU VM을 실행하고 있습니다 .

이것이 나의 환경이라면, 나는 그것이 지나치게 과다 프로비저닝 되는 것을 고려할 것 입니다. 최대 4 ~ 6 개의 4vCPU 게스트를 해당 하드웨어에 배치했습니다. (이것은 문제의 VM에 vCPU 수가 많은 것을 요구하는 부하가 있다고 가정합니다.)

나는 당신이 황금률을 모른다고 가정합니다 ... VMware를 사용하면 VM에 필요한 것보다 많은 코어를 할당해서는 안됩니다. 이유? VMware는 다소 엄격한 공동 스케줄링을 사용하므로 VM에 할당 된 코어 수만큼 코어가 없으면 VM이 CPU 시간을 확보하기 어렵습니다. 즉, 4 개의 물리적 코어가 동시에 열려 있지 않으면 4vCPU VM은 1 개의 작업 단위를 수행 할 수 없습니다. 즉, CPU로드가 90 % 인 1vCPU VM을 보유한 다음 코어 당로드가 45 % 인 2vCPU VM을 사용하는 것이 구조적으로 더 좋습니다.

따라서 ... 항상 최소 vCPU로 VM을 생성하고 필요할 때만 추가하십시오.

상황에 따라 Veeam을 사용하여 게스트의 CPU 사용량을 모니터링하십시오. vCPU 수를 최대한 줄이십시오. 거의 모든 기존 4vCPU 게스트에서 2vCPU로 떨어 뜨릴 수 있다고 확신합니다.

물론, 이러한 모든 VM에 실제로 vCPU 수를 요구하기 위해 CPU로드가있는 경우 추가 하드웨어를 구매하면됩니다.

127,835.94 밀리 초는 합계이므로 정확한 % RDY 값을 얻으려면 샘플 시간으로 나눠야합니다. 그래도 이미 올바른 % RDY 판독 값을 얻는 것 같습니다. vCPU 대 물리적 CPU 비율은 상당히 높지만 수행 방식은 아닙니다.

쿼드 vCPU VM과 8 개의 vCPU VM이 너무 많습니다. 올바른 크기 조정에 대한 몇 가지 품질 응답이 있으며 적은 vCPU로주기를 통합하지 않은 경우의 결과가 있습니다. 내가 명확히하고 싶었던 것은 더 이상 VM이 명령을 처리하기 전에 사용 가능한 vCPU 수와 동일한 물리적 CPU 수를 기다릴 필요가 없지만 매우 해롭다는 것입니다. 다중 vCPU VM과 물리적 코어의 비율로이 규모를 과도하게 프로비저닝합니다. 8 개의 코어에있는 64 개의 vCPU는 최대 4 대 1의 비율을 초과합니다. 이 프로세서에 HT가 있다고 가정하면 16 개의 논리 코어가 있습니까? 로드가 적은 1 및 2 개의 vCPU VM에서는 문제가 없지만 VM에로드가 많으면 달성하기 어렵습니다.

참고 HT 프로세서는 CPU 사용률 계산에 사용되지 않습니다. 즉, 서버의 2.4GHz에서 32 개의 논리 코어를 실행하는 경우 38.4GHz에 도달하면 사용량이 100 %입니다. 따라서 부하 평균이 1.0 이상으로 표시되는 이유가 여기에 있습니다.

다음은 평균 % RDY가 3 % 인 3.5 대 1 vCPU 대 물리적 CPU (HT 코어 포함) 비율을 실행하는 ESXi 호스트입니다.

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

그 이후로 Veeam ONE을 설치하여 성능 문제가있는 위치를 상당히 밝혔습니다. Veeam ONE의 CPU 병목 현상 화면을보고 응답이 중지 된 가상 시스템 문제 해결 : VMM 및 게스트 CPU 사용량 비교 를 참조로 사용하여 "허용 할 수없는"경합이 어디에 있는지 파악했습니다.

구체적으로 공유하고 싶었던 한 가지 작은 팁은 VM에있는 스냅 샷을 제거 할 때까지 CPU 경합을 제거 할 수 없다는 것입니다. 이것이 누군가를 돕기를 바랍니다.