Jeśli zarządzasz wirtualną infrastrukturą opartą na VMware vSphere (lub innym stosie technologii), z pewnością często słyszysz od użytkowników skargi: „Wirtualna maszyna działa wolno!”. W tym cyklu artykułów omówię metryki wydajności, wyjaśnię, co i dlaczego „przycina” oraz jak sprawić, aby nie „przycinało”.
Będę rozważać następujące aspekty wydajności wirtualnych maszyn:
- CPU,
- RAM,
- DYSK,
- Sieć.
Zacznę od CPU.
Do analizy wydajności będziemy potrzebować:
- vCenter Performance Counters – liczniki wydajności, których wykresy można oglądać przez vSphere Client. Informacje dotyczące tych liczników są dostępne w każdej wersji klienta (klient „gruby” w C#, klient webowy w Flex i klient webowy w HTML5). W tych artykułach będziemy używać zrzutów ekranu z klienta C#, ponieważ lepiej wyglądają w miniaturze :)
- ESXTOP – narzędzie, które uruchamia się z wiersza poleceń ESXi. Dzięki niemu można uzyskać wartości liczników wydajności w czasie rzeczywistym lub wyeksportować te dane na określony okres do pliku .csv w celu dalszej analizy. Następnie omówię to narzędzie bardziej szczegółowo i podam kilka przydatnych linków do dokumentacji i artykułów na ten temat.
Trochę teorii
W ESXi za pracę każdego vCPU (jądra wirtualnej maszyny) odpowiada oddzielny proces – world w terminologii VMware. Istnieją także procesy pomocnicze, ale z punktu widzenia analizy wydajności VM są one mniej interesujące.
Proces w ESXi może znajdować się w jednym z czterech stanów:
- Run – proces wykonuje jakąś użyteczną pracę.
- Oczekiwanie – proces nie wykonuje żadnej pracy (idle) lub czeka na wejście/wyjście.
- Costop — stan, który występuje w wirtualnych maszynach wielordzeniowych. Powstaje, gdy planista CPU hipernadzorcy (ESXi CPU Scheduler) nie jest w stanie zaplanować jednoczesnego wykonania wszystkich aktywnych rdzeni wirtualnej maszyny na fizycznych rdzeniach serwera. W rzeczywistości wszystkie rdzenie procesora działają równolegle, a system operacyjny gościa w maszynie wirtualnej polega na podobnym zachowaniu, dlatego hipernadzorca musi spowolnić rdzenie maszyny wirtualnej, które mają możliwość szybszego zakończenia cyklu. W nowoczesnych wersjach ESXi planista CPU korzysta z mechanizmu, który nazywa się relaksowanym współplanowaniem (relaxed co-scheduling): hipernadzorca ocenia różnicę między najszybszym a najwolniejszym rdzeniem wirtualnej maszyny (skew). Jeśli różnica ta przekroczy określony próg, „szybki” rdzeń przechodzi w stan costop. Jeśli rdzenie maszyny wirtualnej spędzają dużo czasu w tym stanie, może to prowadzić do problemów z wydajnością.
- Gotowy — proces przechodzi w ten stan, gdy hipernadzorca nie ma możliwości przydzielenia zasobów do jego wykonania. Wysokie wartości ready mogą powodować problemy z wydajnością maszyny wirtualnej.
Główne liczniki wydajności CPU maszyny wirtualnej
Zużycie CPU, %. Pokazuje procent wykorzystania CPU w zadanym okresie.
Jak analizować? Jeśli maszyna wirtualna stabilnie wykorzystuje CPU na poziomie 90% lub występują szczyty do 100%, mamy problem. Problemy mogą manifestować się nie tylko w formie „wolnej” pracy aplikacji wewnątrz maszyny wirtualnej, ale także w niedostępności maszyny wirtualnej w sieci. Jeśli system monitorowania pokazuje, że maszyna wirtualna okresowo traci połączenie, zwróć uwagę na szczyty na wykresie zużycia CPU.
Istnieje standardowy alarm, który pokazuje obciążenie CPU maszyny wirtualnej:
Co robić? Jeśli zużycie CPU maszyny wirtualnej nieustannie przekracza dopuszczalne wartości, warto pomyśleć o zwiększeniu liczby vCPU (niestety, nie zawsze to pomaga) lub przeniesieniu maszyny wirtualnej na serwer z wydajniejszymi procesorami.
Zużycie CPU w MHz
Na wykresach w vCenter można zobaczyć zużycie CPU w % tylko dla całej maszyny wirtualnej, nie ma wykresów dla poszczególnych rdzeni (w Esxtop wartości % są dostępne dla rdzeni). Można zobaczyć zużycie w MHz dla każdego rdzenia.
Jak analizować? Czasami zdarza się, że aplikacja nie jest zoptymalizowana pod kątem architektury wielordzeniowej: wykorzystuje w 100% tylko jeden rdzeń, podczas gdy pozostałe pozostają nieobciążone. Na przykład, przy domyślnych ustawieniach kopii zapasowej MS SQL uruchamia proces tylko na jednym rdzeniu. W rezultacie tworzenie kopii zapasowej nie jest wolne z powodu niskiej prędkości dysków (na co użytkownik pierwotnie narzekał), lecz z powodu niedoboru mocy procesora. Problem został rozwiązany poprzez zmianę parametrów: tworzenie kopii zapasowej zaczęło uruchamiać się równolegle w kilku plikach (odpowiednio, w kilku procesach).
Przykład nierównomiernego obciążenia rdzeni.
Zdarza się również sytuacja (jak na powyższym wykresie), kiedy rdzenie są obciążone nierównomiernie, a niektóre z nich osiągają szczyty na poziomie 100%. Tak jak w przypadku obciążenia tylko jednego rdzenia, alarm dotyczący użycia CPU nie zadziała (dotyczy to całej VM), ale problemy z wydajnością będą obecne.
Co robić? Jeśli oprogramowanie w maszynie wirtualnej obciąża rdzenie nierównomiernie (wykorzystuje tylko jeden rdzeń lub część rdzeni), nie ma sensu zwiększać ich liczby. W takim przypadku lepiej przenieść maszynę wirtualną na serwer z bardziej wydajnymi procesorami.
Można również spróbować sprawdzić ustawienia oszczędzania energii w BIOSie serwera. Wiele osób administrujących włącza w BIOSie tryb Wysoka Wydajność, tym samym wyłączając technologie oszczędzania energii C-states i P-states. W nowoczesnych procesorach Intel stosowana jest technologia Turbo Boost, która zwiększa częstotliwość poszczególnych rdzeni procesora kosztem innych rdzeni. Ale działa ona tylko przy włączonych technologiach oszczędzania energii. Jeśli je wyłączymy, procesor nie może zredukować zużycia energii rdzeni, które nie są obciążone.
VMware zaleca, aby na serwerach nie wyłączać technologii oszczędzania energii, lecz wybierać tryby, które maksymalnie oddają kontrolę nad zużyciem energii hipernadzorowi. W tym przypadku w ustawieniach zarządzania energią hipernadzoru należy wybrać Wysoką Wydajność.
Jeśli w twojej infrastrukturze poszczególne VM (lub rdzenie VM) wymagają wyższej częstotliwości CPU, odpowiednia konfiguracja oszczędzania energii może znacznie poprawić ich wydajność.
CPU Ready (Gotowość)
Jeśli rdzeń VM (vCPU) jest w stanie Ready, nie wykonuje użytecznej pracy. Ten stan występuje, gdy hypervisor nie może znaleźć wolnego fizycznego rdzenia, na który można przypisać proces vCPU maszyny wirtualnej.
Jak analizować? Zwykle, jeśli rdzenie maszyny wirtualnej są w stanie Ready przez ponad 10% czasu, zauważysz problemy z wydajnością. Mówiąc prościej, przez ponad 10% czasu VM czeka na dostępność zasobów fizycznych.
W vCenter można sprawdzić 2 wskaźniki związane z CPU Ready:
- Readiness,
- Ready.
Wartości obu wskaźników można zobaczyć zarówno dla całej VM, jak i dla poszczególnych rdzeni.
Readiness pokazuje wartość bezpośrednio w procentach, ale tylko w Real-time (dane za ostatnią godzinę, interwał pomiaru 20 sekund). Ten wskaźnik najlepiej używać do szybkiego znajdowania problemów.
Wartości wskaźnika Ready można również sprawdzić w perspektywie historycznej. Jest to przydatne do ustalania wzorców i bardziej szczegółowej analizy problemu. Na przykład, jeśli maszyna wirtualna zaczyna mieć problemy z wydajnością w określonym czasie, można porównać interwały podwyższonego wskaźnika CPU Ready z ogólnym obciążeniem serwera, na którym działa ta VM, i podjąć działania w celu zmniejszenia obciążenia (jeśli DRS nie poradził sobie).
Ready w przeciwieństwie do Readiness jest pokazywany nie w procentach, a w milisekundach. To wskaźnik typu Summation, co oznacza, że pokazuje, ile czasu w okresie pomiaru rdzeń VM spędził w stanie Ready. Można przeliczyć tę wartość na procenty za pomocą prostego wzoru:
(Wartość sumaryczna CPU ready / (domyślny interwał aktualizacji wykresu w sekundach * 1000)) * 100 = CPU ready %
Na przykład, dla maszyny wirtualnej na poniższym wykresie, maksymalna wartość Ready dla całej maszyny wirtualnej będzie następująca:
Przy obliczaniu wartości Ready w procentach warto zwrócić uwagę na dwa aspekty:
- Wartość Ready dla całej VM to suma Ready dla rdzeni.
- Interwał pomiaru. Dla Real-time - to 20 sekund, a na przykład na wykresach dziennych - to 300 sekund.
Podczas aktywnego rozwiązywania problemów te proste aspekty można łatwo przeoczyć i stracić cenny czas na rozwiązywanie nieistniejących problemów.
Obliczamy Ready na podstawie danych z wykresu poniżej. (324474/(20*1000))*100 = 1622% dla całej VM. Jeśli spojrzeć na rdzenie, sytuacja wydaje się nieco lepsza: 1622/64 = 25% na rdzeń. W tej sytuacji odkrycie podstępu jest dość proste: wartość Ready jest nierealistyczna. Ale jeśli mówimy o 10-20% dla całej VM z wieloma rdzeniami, to dla każdego rdzenia wartość może być w granicach normy.
Co robić? Wysoka wartość Ready wskazuje, że serwerowi brakuje zasobów procesora do prawidłowego działania maszyn wirtualnych. W takiej sytuacji pozostaje jedynie zmniejszenie przeliczania CPU (vCPU:pCPU). Oczywiste jest, że można to osiągnąć, zmniejszając parametry istniejących VM lub poprzez migrację części VM na inne serwery.
Co-stop
Jak analizować? Ten licznik również ma typ Sumowanie i przelicza się na procenty analogicznie do Ready:
(wartość sumowania CPU co-stop / (domyślny interwał aktualizacji wykresu w sekundach * 1000)) * 100 = CPU co-stop %
Tutaj również należy zwrócić uwagę na liczbę rdzeni na VM i na interwał pomiaru.
W stanie co-stop rdzeń nie wykonuje użytecznej pracy. Przy właściwym doborze rozmiaru VM i normalnym obciążeniu serwera licznik co-stop powinien być bliski zera.
W tej sytuacji obciążenie jest ewidentnie nienormalne :)
Co robić? Jeśli na jednym hipernadzorze działa kilka VM z dużą liczbą rdzeni i występuje przeliczanie CPU, licznik co-stop może wzrosnąć, co prowadzi do problemów z wydajnością tych VM.
Licznik co-stop również wzrośnie, jeśli dla aktywnych rdzeni jednej VM używane są wątki na jednym fizycznym rdzeniu serwera z włączonym hyper-threadingiem. Taka sytuacja może wystąpić, na przykład, jeśli VM ma więcej rdzeni niż fizycznie dostępnych na serwerze, na którym działa, lub jeśli dla VM włączono ustawienie „preferHT”. O tym ustawieniu można przeczytać .
Aby uniknąć problemów z wydajnością VM z powodu wysokiego co-stop, wybieraj rozmiar VM zgodnie z zaleceniami producenta oprogramowania działającego na tej VM oraz z możliwościami fizycznego serwera, na którym działa VM.
Nie dodawaj rdzeni na zapas, może to spowodować problemy z wydajnością nie tylko samej VM, ale również jej sąsiadów na serwerze.
Inne przydatne metryki CPU
Run – ile czasu (ms) w okresie pomiaru vCPU był w stanie RUN, czyli faktycznie wykonywał użyteczną pracę.
Idle – ile czasu (ms) w okresie pomiaru vCPU znajdował się w stanie bezczynności. Wysokie wartości Idle nie są problemem, po prostu vCPU nie miało "czego robić".
Oczekiwanie – ile czasu (ms) w okresie pomiaru vCPU znajdował się w stanie Wait. Ponieważ w tym wskaźniku zawarty jest IDLE, wysokie wartości Wait również nie świadczą o problemach. Jeśli jednak przy wysokim Wait IDLE jest niski, to oznacza, że VM czekała na zakończenie operacji wejścia/wyjścia, co może wskazywać na problemy z wydajnością dysku twardego lub innych wirtualnych urządzeń VM.
Max limitowany – ile czasu (ms) w okresie pomiaru vCPU znajdował się w stanie Ready z powodu nałożonego limitu zasobów. Jeśli wydajność jest niewytłumaczalnie niska, warto sprawdzić wartość tego wskaźnika oraz limit CPU w ustawieniach VM. VM może mieć zastosowane limity, o których nie wiesz. Na przykład, dzieje się tak, gdy VM została sklonowana z szablonu, na którym był nałożony limit CPU.
Swap wait – ile czasu w okresie pomiaru vCPU czekał na operacje z VMkernel Swap. Jeśli wartości tego wskaźnika są większe od zera, to VM na pewno ma problemy z wydajnością. O SWAPie porozmawiamy w artykule na temat wskaźników pamięci operacyjnej.
ESXTOP
Jeśli wskaźniki wydajności w vCenter są dobre do analizy danych historycznych, to bieżąca analiza problemu lepiej przeprowadzać w ESXTOP. Tutaj wszystkie wartości są przedstawione w gotowej formie (nie trzeba niczego tłumaczyć), a minimalny okres pomiaru wynosi 2 sekundy.
Ekran ESXTOP dla CPU wywołuje się klawiszem „c” i wygląda następująco:
Dla wygody można pozostawić tylko procesy wirtualnych maszyn, naciskając Shift-V.
Aby zobaczyć metryki dla poszczególnych rdzeni VM, naciśnij „e” i wprowadź GID interesującej Cię VM (30919 na zrzucie ekranu poniżej):
Krótko omówię kolumny, które są domyślnie wyświetlane. Dodatkowe kolumny można dodać, naciskając „f”.
NWLD (Liczba Światów) – liczba procesów w grupie. Aby rozwinąć grupę i zobaczyć metryki dla każdego procesu (na przykład dla każdego rdzenia wielordzeniowej VM), naciśnij “e”. Jeśli w grupie jest więcej niż jeden proces, wartości metryk dla grupy są równe sumie metryk dla poszczególnych procesów.
%USED – ile cykli CPU serwera wykorzystuje proces lub grupa procesów.
%RUN – ile czasu w okresie pomiaru proces znajdował się w stanie RUN, tzn. wykonywał użyteczną pracę. Różni się od %USED tym, że nie uwzględnia hyper-threadingu, skalowania częstotliwości i czasu spędzonego na zadania systemowe (%SYS).
%SYS – czas poświęcony na zadania systemowe, takie jak: przetwarzanie przerwań, wejście/wyjście, praca sieciowa itp. Wartość może być wysoka, jeśli na VM jest duży ruch wejścia/wyjścia.
%OVRLP – ile czasu fizyczne jądro, na którym działa proces VM, spędziło na zadaniach innych procesów.
Te metryki są ze sobą powiązane w następujący sposób:
%USED = %RUN + %SYS — %OVRLP.
Zazwyczaj metryka %USED jest bardziej informacyjna.
%WAIT – ile czasu w okresie pomiaru proces znajdował się w stanie Wait. Zawiera IDLE.
%IDLE – ile czasu w okresie pomiaru proces znajdował się w stanie IDLE.
%SWPWT – ile czasu w okresie pomiaru vCPU czekał na operację z VMkernel Swap.
%VMWAIT – ile czasu w okresie pomiaru vCPU znajdowało się w stanie oczekiwania na zdarzenie (zwykle wejście/wyjście). Nie ma analogicznego licznika w vCenter. Wysokie wartości wskazują na problemy z wejściem/wyjściem na VM.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Jeśli VM nie używa VMkernel Swap, to przy analizie problemów z wydajnością wskazane jest zwrócenie uwagi na %VMWAIT, ponieważ ta metryka nie uwzględnia czasu, kiedy VM nic nie robił (%IDLE).
%RDY – ile czasu w okresie pomiaru proces znajdował się w stanie Ready.
%CSTP – ile czasu w okresie pomiaru proces znajdował się w stanie costop.
%MLMTD – ile czasu w okresie pomiaru vCPU znajdował się w stanie Ready z powodu ustalonego limitu zasobów.
%WAIT + %RDY + %CSTP + %RUN = 100% – jądro VM przez cały czas znajduje się w jednym z tych czterech stanów.
CPU na hiperwizorze
W vCenter znajdują się również liczniki wydajności CPU dla hiperwizora, ale nie przedstawiają one nic interesującego – to po prostu suma liczników dla wszystkich VM na serwerze.
Najwygodniej jest sprawdzać stan CPU na serwerze na zakładce Podsumowanie:
Dla serwera, tak jak dla maszyny wirtualnej, istnieje standardowy Alarm:
W przypadku dużego obciążenia CPU serwera, VM działające na nim zaczynają mieć problemy z wydajnością.
W ESXTOP dane o obciążeniu CPU serwera przedstawione są w górnej części ekranu. Oprócz standardowego obciążenia CPU, które jest mało informacyjne dla hypervisorów, istnieją jeszcze trzy metryki:
OBLIKO UTIL(%) – obciążenie rdzenia fizycznego serwera. Ten licznik pokazuje, ile czasu w okresie pomiaru rdzeń wykonywał pracę.
PCPU UTIL(%) – jeśli włączony jest hyper-threading, na każde fizyczne rdzeń przypadają dwa wątki (PCPU). Ta metryka pokazuje, ile czasu każdy wątek wykonywał pracę.
PCPU USED(%) – to samo, co PCPU UTIL(%), ale uwzględnia scaling częstotliwości (czy to obniżenie częstotliwości rdzenia w celu oszczędzania energii, czy to zwiększenie częstotliwości rdzenia dzięki technologii Turbo Boost) i hyper-threading.
PCPU_USED% = PCPU_UTIL% * efektywna częstotliwość rdzenia / nominalna częstotliwość rdzenia.
Na tym zrzucie ekranu dla niektórych rdzeni z powodu działania Turbo Boost, wartość USED przekracza 100%, ponieważ częstotliwość rdzenia jest wyższa niż nominalna.
Kilka słów o tym, jak uwzględniany jest hyper-threading. Jeśli procesy są wykonywane przez 100% czasu na obu wątkach fizycznego rdzenia serwera, a rdzeń pracuje na nominalnej częstotliwości, to:
- OBLIKO UTIL dla rdzenia będzie wynosić 100%,
- PCPU UTIL dla obu wątków będzie wynosić 100%,
- PCPU USED dla obu wątków będzie wynosić 50%.
Jeśli oba wątki nie pracowały przez 100% czasu w okresie pomiaru, to w tych okresach, gdy wątki działały równolegle, PCPU USED dla rdzeni dzieli się na pół.
W ESXTOP znajduje się również ekran z parametrami zużycia energii CPU serwera. Tutaj można sprawdzić, czy serwer korzysta z technologii oszczędzania energii: C-states i P-states. Wywołuje się klawiszem «p»:
Standardowe problemy z wydajnością CPU
Na koniec przejdę przez typowe przyczyny problemów z wydajnością CPU VM i podam krótkie porady ich rozwiązania:
Brakuje taktowania rdzenia. Jeśli nie ma możliwości przeniesienia VM na bardziej wydajne rdzenie, można spróbować zmienić ustawienia zasilania, aby Turbo Boost działał skuteczniej.
Nieprawidłowe rozmiarowanie VM (za dużo/za mało rdzeni). Jeśli ustawi się zbyt mało rdzeni, będzie wysokie obciążenie CPU VM. Jeśli zbyt wiele, można napotkać wysoki co-stop.
Wysoka nadsubskrypcja CPU na serwerze. Jeśli VM ma wysoki stan Ready, należy zmniejszyć nadsubskrypcję CPU.
Nieprawidłowa topologia NUMA w dużych VM. Topologia NUMA, którą widzi VM (vNUMA), powinna odpowiadać topologii NUMA serwera (pNUMA). Diagnoza oraz możliwe rozwiązania tego problemu opisano między innymi w książce . Jeśli nie chcesz zagłębiać się w temat i nie masz ograniczeń licencyjnych dotyczących systemu operacyjnego zainstalowanego na VM, twórz w VM wiele wirtualnych gniazd po jednym rdzeniu. Zbyt wiele nie stracisz 🙂
Na tym kończę temat CPU. Zadawaj pytania. W następnej części opowiem o pamięci operacyjnej.
Przydatne linki
Źródło: habr.com
