Jeśli administrujesz infrastrukturą wirtualną opartą na VMware vSphere (lub innym stosie technologicznym) zapewne często słyszysz skargi użytkowników: „Maszyna wirtualna działa wolno!” W tej serii artykułów przeanalizuję wskaźniki wydajności i powiem, co i dlaczego spowalnia oraz jak się upewnić, że nie spowalnia.
Rozważę następujące aspekty wydajności maszyny wirtualnej:
- CPU,
- BARAN,
- DYSK,
- Sieć.
Zacznę od procesora.
Do analizy wydajności będziemy potrzebować:
- Liczniki wydajności vCenter – liczniki wydajności, których wykresy można przeglądać poprzez klienta vSphere. Informacje o tych licznikach dostępne są w dowolnej wersji klienta („gruby” klient w C#, klient WWW w Flex i klient WWW w HTML5). W tych artykułach będziemy wykorzystywać zrzuty ekranu z klienta C#, tylko dlatego, że lepiej wyglądają w miniaturze :)
- ESXTOP – narzędzie uruchamiane z wiersza poleceń ESXi. Za jego pomocą można uzyskać wartości liczników wydajności w czasie rzeczywistym lub przesłać te wartości za określony okres do pliku .csv w celu dalszej analizy. Następnie opowiem Ci więcej o tym narzędziu i podam kilka przydatnych linków do dokumentacji i artykułów na ten temat.
Trochę teorii
W ESXi za pracę każdego vCPU (rdzeń maszyny wirtualnej) odpowiada odrębny proces – świat w terminologii VMware. Istnieją również procesy usługowe, 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ąś pożyteczną pracę.
- Czekać – proces nie wykonuje żadnej pracy (bezczynny) lub oczekuje na wejście/wyjście.
- Koszt – stan występujący w wielordzeniowych maszynach wirtualnych. Występuje, gdy harmonogram procesora hypervisora (program planujący procesor ESXi) nie może zaplanować jednoczesnego wykonywania wszystkich aktywnych rdzeni maszyn wirtualnych na rdzeniach serwerów fizycznych. W świecie fizycznym wszystkie rdzenie procesorów pracują równolegle, system operacyjny gościa w maszynie wirtualnej oczekuje podobnego zachowania, więc hiperwizor musi spowalniać rdzenie maszyn wirtualnych, które mają możliwość szybszego kończenia cyklu zegara. We współczesnych wersjach ESXi harmonogram procesora korzysta z mechanizmu zwanego swobodnym współdzieleniem harmonogramu: hiperwizor uwzględnia różnicę między „najszybszym” i „najwolniejszym” rdzeniem maszyny wirtualnej (pochylenie). Jeżeli przerwa przekracza określony próg, szybki rdzeń przechodzi w stan zatrzymania. Jeśli rdzenie maszyn wirtualnych spędzają dużo czasu w tym stanie, może to powodować problemy z wydajnością.
- Gotowy – proces wchodzi w ten stan, gdy hypervisor nie jest w stanie przydzielić zasobów do jego wykonania. Wysokie wartości gotowości mogą powodować problemy z wydajnością maszyny wirtualnej.
Podstawowe liczniki wydajności procesora maszyny wirtualnej
Użycie procesora, %. Pokazuje procent wykorzystania procesora w danym okresie.
Jak analizować? Jeśli maszyna wirtualna stale wykorzystuje procesor na poziomie 90% lub występują szczyty dochodzące do 100%, oznacza to problemy. Problemy mogą wyrażać się nie tylko w „wolnym” działaniu aplikacji wewnątrz VM, ale także w niedostępności VM przez sieć. Jeśli system monitorowania pokazuje, że maszyna wirtualna okresowo przestaje działać, zwróć uwagę na wartości szczytowe na wykresie użycia procesora.
Istnieje standardowy alarm pokazujący obciążenie procesora maszyny wirtualnej:
Co robić? Jeśli użycie procesora maszyny wirtualnej stale rośnie, możesz pomyśleć o zwiększeniu liczby procesorów wirtualnych (niestety nie zawsze to pomaga) lub przeniesieniu maszyny wirtualnej na serwer z mocniejszymi procesorami.
Użycie procesora w MHz
Na wykresach w vCenter Użycie w % widać tylko dla całej maszyny wirtualnej, nie ma wykresów dla poszczególnych rdzeni (w Esxtop są wartości % dla rdzeni). Dla każdego rdzenia możesz zobaczyć użycie w MHz.
Jak analizować? Zdarza się, że aplikacja nie jest zoptymalizowana pod architekturę wielordzeniową: wykorzystuje tylko jeden rdzeń w 100%, a pozostałe są bezczynne i bez obciążenia. Na przykład przy domyślnych ustawieniach tworzenia kopii zapasowych MS SQL rozpoczyna proces tylko na jednym rdzeniu. W rezultacie tworzenie kopii zapasowych spowalnia nie z powodu małej prędkości dysków (na to początkowo skarżył się użytkownik), ale dlatego, że procesor nie radzi sobie z tym. Problem został rozwiązany poprzez zmianę parametrów: kopia zapasowa zaczęła działać 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), gdy rdzenie są obciążone nierównomiernie i niektóre z nich osiągają szczyty 100%. Podobnie jak w przypadku ładowania tylko jednego rdzenia, alarm użycia procesora nie będzie działał (dotyczy całej maszyny wirtualnej), ale wystąpią problemy z wydajnością.
Co robić? Jeśli oprogramowanie na maszynie wirtualnej ładuje 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 mocniejszymi procesorami.
Możesz także spróbować sprawdzić ustawienia zużycia energii w BIOSie serwera. Wielu administratorów włącza tryb wysokiej wydajności w systemie BIOS, wyłączając w ten sposób technologie oszczędzania energii w stanach C i P. Nowoczesne procesory Intel wykorzystują technologię Turbo Boost, która zwiększa częstotliwość poszczególnych rdzeni procesora kosztem innych rdzeni. Działa to jednak tylko wtedy, gdy włączone są technologie oszczędzające energię. Jeśli je wyłączymy, procesor nie będzie w stanie zmniejszyć zużycia energii przez nieobciążone rdzenie.
Firma VMware zaleca, aby nie wyłączać technologii oszczędzania energii na serwerach, ale wybierać tryby, które w jak największym stopniu pozostawiają zarządzanie energią hiperwizorowi. W takim przypadku w ustawieniach zużycia energii hypervisora należy wybrać opcję Wysoka wydajność.
Jeśli w Twojej infrastrukturze znajdują się pojedyncze maszyny wirtualne (lub rdzenie maszyn wirtualnych), które wymagają zwiększonej częstotliwości procesora, prawidłowe dostosowanie zużycia energii może znacząco poprawić ich wydajność.
Procesor gotowy
Jeśli rdzeń maszyny wirtualnej (vCPU) jest w stanie gotowości, nie wykonuje użytecznej pracy. Stan taki ma miejsce, gdy hypervisor nie znajdzie wolnego rdzenia fizycznego, do którego można przypisać proces vCPU maszyny wirtualnej.
Jak analizować? Zazwyczaj, jeśli rdzenie maszyny wirtualnej są w stanie Gotowe przez ponad 10% czasu, można zauważyć problemy z wydajnością. Mówiąc najprościej, przez ponad 10% czasu maszyna wirtualna czeka na dostępność zasobów fizycznych.
W vCenter możesz zobaczyć 2 liczniki związane z gotowością procesora:
- gotowość,
- Gotowy.
Wartości obu liczników można przeglądać zarówno dla całej VM, jak i dla poszczególnych rdzeni.
Gotowość pokazuje wartość natychmiast w procentach, ale tylko w czasie rzeczywistym (dane z ostatniej godziny, interwał pomiaru 20 sekund). Lepiej używać tego licznika tylko i wyłącznie do szukania problemów „depczących po piętach”.
Gotowe wartości liczników można oglądać także z perspektywy historycznej. Jest to przydatne do ustalenia wzorców i głębszej analizy problemu. Na przykład, jeśli w pewnym momencie maszyna wirtualna zacznie doświadczać problemów z wydajnością, możesz porównać odstępy czasu gotowości procesora z całkowitym obciążeniem serwera, na którym działa ta maszyna wirtualna, i podjąć kroki w celu zmniejszenia obciążenia (jeśli DRS kończy się niepowodzeniem).
Gotowość, w przeciwieństwie do gotowości, jest pokazywana nie w procentach, ale w milisekundach. Jest to licznik typu sumującego, czyli pokazuje, jak długo w okresie pomiarowym rdzeń maszyny wirtualnej znajdował się w stanie gotowości. Możesz przeliczyć tę wartość na procent za pomocą prostego wzoru:
(Wartość sumowania gotowości procesora / (domyślny interwał aktualizacji wykresu w sekundach * 1000)) * 100 = % gotowości procesora
Na przykład dla maszyny wirtualnej na poniższym wykresie szczytowa wartość gotowości dla całej maszyny wirtualnej będzie następująca:
Obliczając procent gotowości, należy zwrócić uwagę na dwa punkty:
- Wartość gotowości dla całej maszyny wirtualnej jest sumą stanu gotowości dla wszystkich rdzeni.
- Interwał pomiaru. Dla czasu rzeczywistego jest to 20 sekund, a na przykład na wykresach dziennych jest to 300 sekund.
Dzięki aktywnemu rozwiązywaniu problemów można łatwo przeoczyć te proste punkty, a cenny czas można zmarnować na rozwiązywanie nieistniejących problemów.
Obliczmy Gotowość na podstawie danych z poniższego wykresu. (324474/(20*1000))*100 = 1622% dla całej maszyny wirtualnej. Jeśli spojrzeć na rdzenie, nie jest to takie straszne: 1622/64 = 25% na rdzeń. W tym przypadku haczyk jest dość łatwy do wykrycia: wartość gotowości jest nierealistyczna. Ale jeśli mówimy o 10–20% dla całej maszyny wirtualnej z kilkoma rdzeniami, to dla każdego rdzenia wartość może mieścić się w normalnym zakresie.
Co robić? Wysoka wartość Ready wskazuje, że serwer nie ma wystarczających zasobów procesora do normalnej pracy maszyn wirtualnych. W takiej sytuacji pozostaje jedynie ograniczenie nadsubskrypcji ze względu na procesor (vCPU:pCPU). Można to oczywiście osiągnąć poprzez zmniejszenie parametrów istniejących maszyn wirtualnych lub migrację części maszyn wirtualnych na inne serwery.
Wspólny przystanek
Jak analizować? Ten licznik jest również typu Sumowanie i jest konwertowany na wartości procentowe w taki sam sposób jak Gotowy:
(Wartość sumowania wspólnych zatrzymań procesora / (domyślny interwał aktualizacji wykresu w sekundach * 1000)) * 100 = % wspólnych zatrzymań procesora
Tutaj również należy zwrócić uwagę na liczbę rdzeni na maszynie wirtualnej i interwał pomiaru.
W stanie costop jądro nie wykonuje użytecznej pracy. Przy prawidłowym dobraniu rozmiaru maszyny wirtualnej i normalnym obciążeniu serwera, licznik współzatrzymań powinien być bliski zeru.
W tym przypadku obciążenie jest wyraźnie nienormalne :)
Co robić? Jeśli na jednym hypervisorze działa kilka maszyn wirtualnych z dużą liczbą rdzeni i występuje nadsubskrypcja procesora, wówczas licznik współzatrzymań może wzrosnąć, co doprowadzi do problemów z wydajnością tych maszyn wirtualnych.
Ponadto liczba przestojów wzrośnie, jeśli aktywne rdzenie jednej maszyny wirtualnej będą korzystać z wątków na jednym rdzeniu serwera fizycznego z włączoną funkcją Hyper-Treading. Taka sytuacja może wystąpić na przykład, jeśli maszyna wirtualna ma więcej rdzeni niż fizycznie dostępnych na serwerze, na którym jest uruchomiona, lub jeśli dla maszyny wirtualnej włączono ustawienie „preferHT”. Możesz przeczytać o tym ustawieniu .
Aby uniknąć problemów z wydajnością VM spowodowanych wysokim co-stopem, należy wybrać rozmiar VM zgodnie z zaleceniami producenta oprogramowania działającego na tej VM oraz możliwościami serwera fizycznego, na którym działa VM.
Nie dodawaj rdzeni do rezerwy; może to spowodować problemy z wydajnością nie tylko samej maszyny wirtualnej, ale także jej sąsiadów na serwerze.
Inne przydatne wskaźniki procesora
run – ile czasu (ms) w okresie pomiarowym vCPU znajdował się w stanie RUN, czyli faktycznie wykonywał użyteczną pracę.
Idle – jak długo (ms) w okresie pomiarowym vCPU znajdowało się w stanie bezczynności. Wysokie wartości Idle nie są problemem, vCPU po prostu „nie miał nic do roboty”.
Czekać – jak długo (ms) w okresie pomiarowym vCPU znajdowało się w stanie oczekiwania. Ponieważ IDLE jest uwzględnione w tym liczniku, wysokie wartości Wait również nie wskazują na problem. Jeśli jednak wartość Wait IDLE jest niska, a wartość Wait jest wysoka, oznacza to, że maszyna wirtualna czekała na zakończenie operacji we/wy, a to z kolei może wskazywać na problem z wydajnością dysku twardego lub jakichkolwiek urządzeń wirtualnych maszyny wirtualnej.
Maks limitowany – jak długo (ms) w okresie pomiarowym vCPU znajdowało się w stanie Gotowy ze względu na ustawiony limit zasobów. Jeśli wydajność jest niewytłumaczalnie niska, warto sprawdzić wartość tego licznika i limit procesora w ustawieniach maszyny wirtualnej. Maszyny wirtualne mogą rzeczywiście mieć ograniczenia, o których nie wiesz. Dzieje się tak na przykład, gdy maszyna wirtualna została sklonowana z szablonu, dla którego ustawiono limit procesora.
Zamień, czekaj – jak długo w okresie pomiarowym vCPU czekał na operację z VMkernel Swap. Jeżeli wartości tego licznika są powyżej zera, to maszyna wirtualna na pewno ma problemy z wydajnością. Więcej o SWAP-ie porozmawiamy w artykule o licznikach RAM.
ESXTOP
Jeśli liczniki wydajności w vCenter są dobre do analizy danych historycznych, wówczas analizę operacyjną problemu lepiej przeprowadzić w ESXTOP. Tutaj wszystkie wartości prezentowane są w gotowej formie (nie trzeba niczego tłumaczyć), a minimalny okres pomiaru to 2 sekundy.
Ekran ESXTOP dla procesora wywoływany jest klawiszem „c” i wygląda następująco:
Dla wygody możesz pozostawić tylko procesy maszyny wirtualnej, naciskając Shift-V.
Aby wyświetlić metryki poszczególnych rdzeni maszyn wirtualnych, naciśnij „e” i wprowadź GID interesującej maszyny wirtualnej (30919 na zrzucie ekranu poniżej):
Przejdźmy pokrótce przez kolumny, które są prezentowane domyślnie. 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 w wielordzeniowej maszynie wirtualnej), naciśnij „e”. Jeśli w grupie znajduje się więcej niż jeden proces, wówczas wartości metryki dla grupy są równe sumie metryk dla poszczególnych procesów.
%UŻYWANY – ile cykli procesora serwera wykorzystuje proces lub grupa procesów.
%URUCHOMIĆ – jak długo w okresie pomiarowym proces znajdował się w stanie RUN, tj. wykonał pożyteczną pracę. Różni się od %USED tym, że nie uwzględnia hiperwątkowości, skalowania częstotliwości i czasu spędzonego na zadaniach systemowych (%SYS).
%SYS – czas spędzony na zadaniach systemowych, np.: przetwarzanie przerwań, we/wy, działanie sieciowe itp. Wartość może być wysoka, jeśli maszyna wirtualna ma duże we/wy.
%OVRLP – ile czasu fizyczny rdzeń, na którym działa proces VM, spędza na zadaniach innych procesów.
Wskaźniki te są ze sobą powiązane w następujący sposób:
%USED = %RUN + %SYS - %OVRLP.
Zazwyczaj metryka %USED dostarcza więcej informacji.
%CZEKAĆ – jak długo w okresie pomiarowym proces znajdował się w stanie Oczekiwanie. Włącza bezczynność.
%BEZCZYNNY – jak długo w okresie pomiarowym proces znajdował się w stanie IDLE.
%SWPWT – jak długo w okresie pomiarowym vCPU czekał na operację z VMkernel Swap.
%VMWAIT – jak długo w okresie pomiarowym vCPU znajdował się w stanie oczekiwania na zdarzenie (zwykle I/O). W vCenter nie ma podobnego licznika. Wysokie wartości wskazują na problemy z we/wy na maszynie wirtualnej.
%WAIT = %VMWAIT + %IDLE + %SWPWT.
Jeśli maszyna wirtualna nie korzysta z VMkernel Swap, wówczas przy analizie problemów z wydajnością wskazane jest sprawdzenie %VMWAIT, ponieważ ta metryka nie uwzględnia czasu, kiedy maszyna wirtualna nic nie robiła (%IDLE).
%RDY – jak długo w okresie pomiarowym proces znajdował się w stanie Gotowy.
%CSTP – jak długo w okresie pomiarowym proces znajdował się w stanie coststop.
%MLMTD – jak długo w okresie pomiarowym vCPU znajdował się w stanie Gotowy ze względu na ustawiony limit zasobów.
%WAIT + %RDY + %CSTP + %RUN = 100% – rdzeń maszyny wirtualnej jest zawsze w jednym z tych czterech stanów.
Procesor na hypervisorze
vCenter posiada również liczniki wydajności procesora dla hypervisora, ale nie są one niczym ciekawym - są po prostu sumą liczników dla wszystkich maszyn wirtualnych na serwerze.
Najwygodniejszym sposobem sprawdzenia stanu procesora na serwerze jest zakładka Podsumowanie:
Dla serwera, jak i dla maszyny wirtualnej istnieje standardowy Alarm:
Gdy obciążenie procesora serwera jest wysokie, działające na nim maszyny wirtualne zaczynają doświadczać problemów z wydajnością.
W ESXTOP dane dotyczące obciążenia procesora serwera prezentowane są na górze ekranu. Oprócz standardowego obciążenia procesora, które nie jest zbyt pouczające dla hypervisorów, istnieją jeszcze trzy metryki:
PODSTAWOWE WYKORZYSTANIE (%) – ładowanie rdzenia serwera fizycznego. Licznik ten pokazuje, ile czasu rdzeń wykonywał pracę w okresie pomiarowym.
WYKORZYSTANIE PCPU (%) – jeśli włączona jest funkcja Hyper-Threading, wówczas na każdy rdzeń fizyczny przypadają dwa wątki (PCPU). Ta metryka pokazuje, ile czasu zajęło wykonanie każdego wątku.
WYKORZYSTANY PCPU (%) – taki sam jak PCPU UTIL(%), ale uwzględnia skalowanie częstotliwości (albo zmniejszenie częstotliwości rdzenia w celu oszczędzania energii, albo 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, ze względu na Turbo Boost, wartość USED jest większa niż 100%, ponieważ częstotliwość rdzenia jest wyższa niż nominalna.
Kilka słów o tym, jak uwzględnia się hiperwątkowość. Jeżeli procesy wykonywane są w 100% czasu na obu wątkach fizycznego rdzenia serwera, podczas gdy rdzeń pracuje z nominalną częstotliwością, to:
- CORE UTIL dla rdzenia będzie 100%,
- PCPU UTIL dla obu wątków będzie wynosić 100%,
- UŻYCIE PCPU dla obu wątków będzie wynosić 50%.
Jeżeli w okresie pomiarowym oba wątki nie działały w 100%, to w okresach, w których wątki pracowały równolegle, PCPU WYKORZYSTANE dla rdzeni jest dzielone na pół.
ESXTOP posiada również ekran z parametrami zużycia energii procesora serwera. Tutaj możesz zobaczyć, czy serwer wykorzystuje technologie oszczędzające energię: stany C i stany P. Wywoływany klawiszem „p”:
Typowe problemy z wydajnością procesora
Na koniec omówię typowe przyczyny problemów z wydajnością procesora maszyny wirtualnej i podam krótkie wskazówki, jak je rozwiązać:
Taktowanie rdzenia nie jest wystarczające. Jeśli nie jest możliwe uaktualnienie maszyny wirtualnej do mocniejszych rdzeni, możesz spróbować zmienić ustawienia zasilania, aby Turbo Boost działał wydajniej.
Nieprawidłowy rozmiar maszyny wirtualnej (zbyt wiele/mało rdzeni). Jeśli zainstalujesz kilka rdzeni, maszyna wirtualna będzie obciążona dużym obciążeniem procesora. Jeśli jest ich dużo, złap wysoki przystanek.
Duża nadsubskrypcja procesora na serwerze. Jeśli maszyna wirtualna ma wysoką gotowość, zmniejsz nadsubskrypcję procesora.
Nieprawidłowa topologia NUMA na dużych maszynach wirtualnych. Topologia NUMA widziana przez maszynę wirtualną (vNUMA) musi być zgodna z topologią NUMA serwera (pNUMA). Diagnostyka i możliwe rozwiązania tego problemu są napisane na przykład w książce . Jeśli nie chcesz wchodzić głębiej i nie masz ograniczeń licencyjnych na system operacyjny zainstalowany na maszynie wirtualnej, utwórz wiele wirtualnych gniazd na maszynie wirtualnej, po jednym rdzeniu na raz. Dużo nie stracisz :)
To tyle jeśli chodzi o procesor. Zadawać pytania. W następnej części opowiem o pamięci RAM.
Przydatne linki
Źródło: www.habr.com