Klienci często pytają o czas kradzieży procesora (CPU steal time). Szczególnie ci, którzy intensywnie korzystają z procesorów i dla których jest to kluczowe kryterium wydajności. Istnieje sporo różnic w konfiguracji i zachowaniu procesorów oraz rdzeni między środowiskami fizycznymi a wirtualnymi. Nawet między dostawcami chmury występują różnice w konfiguracji, które utrudniają bezpośrednie porównanie. Z tego powodu uznaliśmy za przydatne przedstawienie krótkiego omówienia naszej konfiguracji i logiki alokacji procesorów dla klientów, a także wyjaśnienie najczęstszych źródeł czasu kradzieży procesora.
Po pierwsze, dla osób niezaznajomionych z tym pojęciem, CPU steal time to czas, przez który wirtualny procesor na serwerze chmurowym musi czekać na rzeczywisty procesor fizyczny, podczas gdy hiperwizor jest zajęty używaniem go do innych celów (takich jak inne maszyny wirtualne/serwery chmurowe). Jest to świetny artykuł na temat CPU steal time który warto przeczytać.
Kilka informacji o naszej konfiguracji procesorów
Pierwszą rzeczą, którą należy zrozumieć, jest sposób, w jaki przydzielamy rdzenie pomiędzy maszyny wirtualne na każdym fizycznym węźle obliczeniowym obsługującym Twoje obliczenia. Procesory i ich rdzenie w CloudSigma są współdzielone. Innymi słowy, nie przypisujemy serwera chmurowego klienta do konkretnych rdzeni. Czas procesora jest przydzielany dynamicznie przez harmonogram fizycznego węzła obliczeniowego i wszystko jest współdzielone. Wierzymy, że przynosi to szereg korzyści w postaci zapewnienia bardziej niezawodnej wydajności jako całości, umożliwiając węzłowi obliczeniowemu dokonywanie rozsądnych korekt alokacji w locie w celu zrównoważenia obciążenia.
W połączeniu z tym używamy Control Groups (w skrócie cgroups), aby zagwarantować wystarczającą ilość czasu procesora dla każdego z serwerów chmurowych, zgodnie z zasobami ustawionymi poprzez rozmiar serwera. Ostatecznie harmonogram decyduje, co zrobić z pozostałymi zasobami i cgroups. Warto również zauważyć, że rezerwujemy zestaw określonych rdzeni, które znajdują się poza zakresem alokacji dla obciążeń obliczeniowych klientów. Używamy tych rdzeni do uruchamiania systemu operacyjnego hosta fizycznego. W szczególności rezerwujemy dodatkowe rdzenie do przetwarzania operacji sieciowych i pamięci masowej. Wszystko to ma na celu zwiększenie stabilności całej maszyny. Ponadto pomaga to zapewnić niezawodny poziom wydajności w czasie, niezależnie od obciążenia generowanego przez innych klientów.
Źródła czasu kradzieży procesora (CPU Steal Time) w środowisku zwirtualizowanym
W przeciwieństwie do środowiska fizycznego, istnieje wiele źródeł i sytuacji, w których można doświadczyć czasu kradzieży procesora. Wynika to z faktu, że w wielodostępnym środowisku zwirtualizowanym sprawy są bardziej skomplikowane. Nie wszystkie z nich oznaczają sytuację, w której nie otrzymujesz należnego czasu procesora – w rzeczywistości w wielu przypadkach możesz często wykorzystać wolne cykle procesora powyżej przydzielonego rozmiaru, ale nie jest to sytuacja, w której zobaczysz CPU steal time. Trzy najczęstsze sytuacje opisano szczegółowo poniżej.
Twój serwer chmurowy jest przeciążony
To się zdarza! Każdy chce wykorzystać opłacone zasoby w stopniu jak najbliższym pełnej wydajności, jednak jeśli procesor przydzielony do wirtualnego serwera chmurowego nie wystarcza do przetworzenia obciążenia, możesz zaobserwować CPU steal time, gdy zadania gromadzą się i tworzą kolejkę w wirtualnym procesorze. Jeśli to jest główna przyczyna występowania CPU steal time, rozwiązaniem jest zmiana rozmiaru serwera chmurowego. Jeśli jest to tymczasowe przeciążenie, możesz bezpiecznie pozostawić wszystko bez zmian. CPU steal time zniknie, gdy obciążenie spadnie.
Serwer fizyczny hostujący Twój serwer chmurowy jest przeciążony
Jeśli dojdzie do przeciążenia hosta, w tym przypadku jest to błąd po naszej stronie. Zdarza się to rzadko, ale może się przytrafić. W takiej sytuacji korzystamy z migracji na żywo, aby bez zakłóceń przenieść maszyny wirtualne na inne fizyczne węzły obliczeniowe i przywrócić obciążenie do normalnego poziomu. Zazwyczaj utrzymujemy obciążenie hostów znacznie poniżej ich maksymalnej wydajności. Jeśli więc obserwujesz to zjawisko przez dłuższy czas, skontaktuj się z nami. Nasze bezpłatne wsparcie techniczne 24/7 może sprawdzić host fizyczny, na którym się znajdujesz. Jeśli nie ma przeciążenia, jest mało prawdopodobne, aby to ono było główną przyczyną CPU steal time.
Używasz mniejszego rozmiaru rdzenia wirtualnego
W CloudSigma dajemy Ci możliwość zdefiniowania rozmiaru rdzenia wirtualnego, aby skorzystać na przykład z większej liczby wątków procesora lub większej liczby mniejszych rdzeni wirtualnych dla dowolnego rozmiaru serwera chmurowego. Serwer chmurowy w systemie operacyjnym zawsze będzie widział rozmiar rdzenia jako pełny rozmiar fizyczny.
Jeśli fizyczny rdzeń ma 2.6GHz, ale Twoja maszyna wirtualna ma 4GHz i dwa rdzenie, każdy wirtualny rdzeń będzie miał 2GHz. Z tego powodu zawsze będziesz widzieć CPU steal time. W rzeczywistości wynika to z faktu, że otrzymujesz proporcjonalną część całkowitego rdzenia, a nie jego pełny rozmiar, ze względu na mniejszy rozmiar rdzenia wirtualnego. W związku z tym należy zawsze dostosować wszelkie obliczenia CPU steal time, aby uwzględnić mniejszy rozmiar rdzenia wirtualnego, jeśli faktycznie z niego korzystasz. Aby tego uniknąć, możesz użyć pełnego rozmiaru rdzenia na rdzeń. Możesz to zrobić, rozszerzając rozmiar rdzenia wirtualnego do pełnego rozmiaru rdzenia procesora (np. Intel v4 2.6GHz).
Podsumowanie
CPU steal time w chmurze jest nieco bardziej skomplikowany niż w tradycyjnych fizycznych środowiskach typu single-tenant. Jednak zdecydowanie nadal istnieje. Raportowanie CPU steal time przez systemy operacyjne nie zostało jednak dostosowane do tych odmiennych warunków. Oznacza to, że można uzyskać fałszywe alarmy. Wykrycie CPU steal time zazwyczaj oznacza, że występuje ograniczenie zasobów. Mamy nadzieję, że ten wpis pomoże Ci szybko zidentyfikować przyczynę i zapewnić dalsze płynne działanie.
Udanych obliczeń!
Robert
Komentarze
Brak komentarzy. Bądź pierwszy.