한동안 저는 업무상 중요한 시스템 중 상당수가 경미함에서 극한까지의 "느림"에 대한 보고를 받는 이유를 알아내려고 노력해 왔습니다. 저는 최근 문제의 모든 서버가 호스팅되는 VMware 환경에 눈을 돌렸습니다.
최근에 SCOM 2012용 Veeam VMware 관리 팩 평가판을 다운로드하여 설치했지만 보고된 수치를 믿기가 어렵습니다(제 상사도 그렇습니다). 나에게 말하는 숫자가 사실이라는 것을 상사에게 설득하기 위해 나는 결과를 확인하기 위해 VMware 클라이언트 자체를 조사하기 시작했습니다.
나는 보았다이 VMware KB 문서; 특히 다음과 같이 정의된 Co-Stop의 정의를 위해:
MP 가상 머신을 실행할 준비가 되었지만 공동 vCPU 예약 경합으로 인해 지연이 발생한 시간입니다.
내가 번역하는 곳
게스트 OS는 호스트로부터 시간이 필요하지만 리소스가 사용 가능해질 때까지 기다려야 하므로 "응답 없음"으로 간주될 수 있습니다.
이 번역이 맞는 것 같나요?
그렇다면 내가 보고 있는 내용을 믿기 어려운 부분은 다음과 같습니다. "느린" VM의 대부분을 포함하는 호스트는 현재 CPU 공동 중지 평균을 표시하고 있습니다.127,835.94밀리초!
이는 평균적으로 이 호스트의 VM이 CPU 시간을 위해 2분 이상 기다려야 함을 의미합니까???
이 호스트에는 2개의 4코어 CPU가 있고 1x8 CPU 게스트와 14x4 CPU 게스트가 있습니다.
답변1
이 분야에서 내가 겪은 몇 가지 경험을 설명할 수 있습니다.
저는 VMware가 고객을 교육하는 데 적절한 역할을 하고 있다고 생각하지 않습니다(또는 관리자) 모범 사례에 대해 설명하지 않으며 제품이 발전함에 따라 이전 모범 사례를 업데이트하지도 않습니다. 이 질문은 vCPU 할당과 같은 핵심 개념이 어떻게 완전히 이해되지 않았는지 보여주는 예입니다. 가장 좋은 접근 방식은 VM에 더 많은 것이 필요하다고 판단될 때까지 단일 vCPU로 소규모로 시작하는 것입니다.
OP의 경우 ESXi 호스트 서버에는 2개의 쿼드 코어 CPU가 있어 8개의 물리적 코어를 생성합니다.
설명되는 가상 머신 레이아웃은 총 15개의 게스트입니다. 1 x 8 vCPU 및 14 x 4 vCPU 시스템. 특히,vCPU가 8개인 단일 게스트. 그것은 말도 안돼. 그렇게 큰 VM이 필요한 경우 더 큰 서버가 필요할 가능성이 높습니다.
시도해 보십시오맞는 치수귀하의 가상 머신. 나는 그들 중 대부분이 2개의 vCPU로 살아갈 수 있다고 확신합니다. 가상 CPU를 추가한다고 해서 작업이 더 빠르게 실행되는 것은 아니므로 이것이 성능 문제에 대한 해결책이라면 취하는 것은 잘못된 접근 방식입니다.
대부분의 환경에서 RAM은 가장 제한된 리소스입니다. 하지만 경합이 너무 많으면 CPU가 문제가 될 수 있습니다. 이에 대한 증거가 있습니다. RAM은 다음과 같은 경우에도 문제가 될 수 있습니다.개별 VM에 너무 많은 양이 할당됨.
이를 모니터링하는 것이 가능합니다. 찾고 있는 측정항목은 "CPU Ready %"입니다. VM을 선택하고 Performance> Overview> CPU 그래프 로 이동하여 vSphere 클라이언트에서 이에 액세스할 수 있습니다 .
- CPU 준비 상태 5% 미만- 너는 괜찮아.
- 5-10% CPU 준비- 활동을 면밀히 살펴보십시오.
- CPU 준비율 10% 이상- 안좋다.
아래 그래프의 노란색 선을 참고하세요.
문제가 있는 가상 머신에서 이를 확인하고 다시 보고하시겠습니까?
답변2
설명에 듀얼 쿼드 코어 ESXi 호스트가 있고 하나의 8vCPU VM을 실행하고 있다고 명시하고 있습니다.십사4vCPU VM.
이것이 내 환경이라면 그렇게 생각할 것이다.크게과잉 프로비저닝. 해당 하드웨어에는 최대 4~6개의 4vCPU 게스트를 배치합니다. (이는 문제의 VM에 높은 vCPU 수가 필요한 부하가 있다고 가정합니다.)
나는 당신이 황금률을 모른다고 가정합니다. VMware를 사용하면 VM에 필요한 것보다 더 많은 코어를 할당해서는 안됩니다. 이유? VMware는 VM이 할당된 만큼 사용 가능한 코어가 없으면 VM이 CPU 시간을 확보하기 어렵게 만드는 다소 엄격한 공동 스케줄링을 사용합니다. 즉, 4vCPU VM은 동시에 4개의 물리적 코어가 열려 있지 않으면 1개의 작업 단위를 수행할 수 없습니다. 즉, CPU 로드가 90%인 1vCPU VM을 사용하는 것보다 코어당 로드가 45%인 2vCPU VM을 사용하는 것이 구조적으로 더 좋습니다.
따라서...항상 최소 vCPU로 VM을 생성하고 필요하다고 판단되는 경우에만 추가하세요.
상황에 따라 Veeam을 사용하여 게스트의 CPU 사용량을 모니터링하세요. vCPU 수를 최대한 줄이세요. 거의 모든 기존 4vCPU 게스트에서 2vCPU로 낮출 수 있다고 확신합니다.
물론 이러한 모든 VM에 실제로 vCPU 수를 요구할 정도로 CPU 로드가 있는 경우 추가 하드웨어를 구입하기만 하면 됩니다.
답변3
127,835.94밀리초는 합산이므로 올바른 %RDY 값을 얻으려면 샘플 시간으로 나누어야 합니다. 하지만 지금은 이미 올바른 %RDY 판독값을 얻고 있는 것 같습니다. vCPU 대 물리적 CPU 비율을 사용하면 상당히 높아질 수 있지만 지금과 같은 방식으로는 그렇지 않습니다.
쿼드 vCPU VM이 너무 많고 vCPU가 8개인 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
......
답변4
그 후 우리는 성능 문제가 어디에 있는지 상당히 밝혀주는 Veeam ONE을 설치했습니다. Veeam ONE의 CPU 병목 현상 화면을 확인한 다음 다음을 사용합니다.응답이 중지된 가상 머신 문제 해결: VMM 및 게스트 CPU 사용량 비교참고로 우리는 "받아들일 수 없는" 주장이 어디에 있는지 알아냈습니다.
제가 구체적으로 공유하고 싶은 작은 팁 중 하나는 VM에 있는 스냅샷을 제거할 때까지 CPU 경합을 제거할 수 없다는 것입니다. 이것이 누군가에게 도움이 되기를 바랍니다.