Czym jest CPU steal time na VPS i jak go sprawdzić

Czym w rzeczywistości jest CPU steal time

CPU steal time to część czasu, w której wirtualny procesor (vCPU) był gotowy do pracy i nie oczekiwał na żadne zasoby, podczas gdy hypervisor przydzielił fizyczny rdzeń innemu gościowi. Zadanie znajdowało się w kolejce. Rdzeń był zajęty gdzie indziej. Linux zlicza te cykle oddzielnie i raportuje je jako st. Pozwala to odróżnić sytuację, w której serwer jest obciążony, od sytuacji, w której serwer czeka na swoją kolej.

Ta różnica jest głównym powodem istnienia licznika. Czas, który własne procesy spędzają na procesorze, jest raportowany jako us (user) lub sy (system). Czas, w którym zadanie jest zablokowane przez operacje dyskowe, raportowany jest jako wa (I/O wait). vCPU, który jest gotowy do pracy, znajduje się w kolejce uruchomieniowej, nie oczekuje na I/O, a mimo to nie wykonuje instrukcji, jest raportowany jako st. Żaden proces wewnątrz serwera nie może zmienić tego stanu, ponieważ decyzje o szeregowaniu zapadają warstwę niżej, na hoście.

Wynika to bezpośrednio z sposobu, w jaki VPS współdzieli jedną maszynę fizyczną między wielu gości. Typową przyczyną jest sąsiedztwo: inny gość na tym samym węźle generuje duże obciążenie, więc host dzieli rdzenie między użytkowników. Istnieje druga, często pomijana przyczyna. Wielu dostawców ogranicza współdzielony vCPU do ułamka fizycznego rdzenia, a w przypadku wielu hypervisorów to wymuszone ograniczenie jest wewnątrz gościa rozliczane jako steal. Zatem wysoki odczyt st informuje, że rdzeń nie został przydzielony. Nie zawsze jednak wskazuje, kto go zajął.

Skąd pochodzi wartość steal

Jądro systemu nie jest w stanie samodzielnie zmierzyć czasu steal, ponieważ nie ma wglądu w stan hosta. Informację tę przekazuje hypervisor. W środowisku KVM host zapisuje licznik dla każdego vCPU w stronie pamięci współdzielonej z gościem, a gość sumuje te wartości, jeśli jądro zostało skompilowane z opcją CONFIG_PARAVIRT_TIME_ACCOUNTING (co jest standardem w każdej dystrybucji). Xen raportuje te same dane poprzez obszar runstate. Sumaryczna wartość trafia do przestrzeni użytkownika w jednym miejscu:

head -1 /proc/stat

Linia cpu zawiera dziesięć liczników w jednostkach USER_HZ od momentu uruchomienia systemu, w następującej kolejności: user, nice, system, idle, iowait, irq, softirq, steal, guest, guest_nice. Wartość steal jest ósmą liczbą po etykiecie. Każde z poniższych narzędzi, vmstat, top, mpstat oraz dowolny eksporter Prometheus, odczytuje to samo pole i na podstawie dwóch próbek oblicza wartość procentową.

Jeden wniosek jest istotniejszy od pozostałych. Jeśli hypervisor nie eksportuje licznika, pole pozostaje stale wyzerowane, a każde narzędzie oparte na tym odczycie będzie raportować wynik 0.0, nawet jeśli host jest przeciążony. KVM i Xen eksportują te dane. Systemy gości na VMware i Hyper-V zazwyczaj raportują stałe zero. Przed zaufaniem wynikowi zero należy sprawdzić platformę:

systemd-detect-virt

Polecenie to wyświetla nazwę platformy, taką jak kvm, xen, vmware lub microsoft, a w przypadku serwerów fizycznych none. Wewnątrz kontenera raportowane jest środowisko uruchomieniowe, na przykład lxc, docker lub podman, co informuje o kontenerze, a nie o maszynie bazowej. Na platformie kvm wartość zero jest wiarygodnym dowodem na to, że host przydziela zasoby poprawnie. Na platformie, która nie wypełnia tego pola, zero nie stanowi żadnego dowodu, a o ewentualnym współzawodnictwie o zasoby należy wnioskować na podstawie pomiaru czasu wykonywania rzeczywistych zadań.

Jak sprawdzić czas steal CPU na VPS?

vmstat pochodzi z pakietu procps. Jest obecny w niemal każdym obrazie VPS z systemami Ubuntu i Debian, a brakuje go w niektórych minimalnych obrazach kontenerów, dlatego należy go zainstalować przed użyciem.

sudo apt-get update
sudo apt-get install -y procps
vmstat --version
vmstat 1 5

vmstat --version wyświetla wiersz taki jak vmstat from procps-ng 4.0.4. Jeśli polecenie działa, narzędzie jest zainstalowane, a odczyty pochodzą z rzeczywistych liczników jądra. vmstat 1 5 pobiera jedną próbkę na sekundę, łącznie pięć razy.

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 1  0      0 3216484  98304 1284360    0    0     4    18   62  110  3  1 96  0  0  0
 2  0      0 3216232  98304 1284360    0    0     0     0  248  431  6  2 84  0  8  0

Należy odnaleźć kolumnę st w bloku cpu po prawej stronie. Aktualne kompilacje procps-ng wyświetlają kolumnę gu dla czasu gościa KVM, dlatego st znajduje się przedostatnio, a nie na końcu. Należy kierować się nazwą nagłówka kolumny, ponieważ jej pozycja zmieniała się między wydaniami.

Dwa nawyki zapewniają rzetelność odczytu. Pierwszy wiersz danych to średnia od momentu uruchomienia systemu, dlatego należy go zignorować i analizować kolejne wiersze. Jedna próbka nie stanowi pomiaru, ponieważ czas steal występuje w skokach: należy uruchomić vmstat 1 60 i obserwować dane przez pełną minutę przed wyciągnięciem wniosków.

top raportuje tę samą wartość w wierszu podsumowania %Cpu(s), w polu oznaczonym jako st:

%Cpu(s):  6.2 us,  2.1 sy,  0.0 ni, 83.9 id,  0.0 wa,  0.0 hi,  0.3 si,  7.5 st

Aby uzyskać szczegółowe dane dla każdego rdzenia, należy dodać sysstat:

sudo apt-get install -y sysstat
mpstat -P ALL 1 5

mpstat wyświetla jeden wiersz na każdy procesor z kolumną %steal, co pozwala sprawdzić, czy problem dotyczy każdego vCPU, czy tylko jednego. Na potrzeby zgłoszenia serwisowego należy zachować próbki zamiast odczytywać je bezpośrednio z ekranu:

date -u | tee -a ~/steal.log
mpstat -P ALL 1 5 | tee -a ~/steal.log

Polecenie to należy uruchamiać przez cron w godzinach, w których występuje podejrzenie problemów. Plik z wynikami stanowi różnicę między zgłoszeniem do dostawcy treści „działało wolno w nocy” a przedstawieniem dokładnych dziesięciu minut występowania anomalii.

Co oznaczają wartości steal?

• Stałe 0.0. System jest w dobrym stanie lub platforma w ogóle nie raportuje wartości steal. Przed wyciągnięciem wniosków należy zweryfikować to za pomocą systemd-detect-virt.
• Skoki o kilka procent trwające sekundy. Zjawisko normalne na każdym współdzielonym węźle. Może wynikać z uruchomienia procesu budowania u sąsiada lub wykonywania kopii zapasowych przez hosta.
• Utrzymujące się od 1 do 5 procent w planie współdzielonym. Wartość oczekiwana. Cena odzwierciedla współdzielony charakter procesora.
• Utrzymujące się od 5 do 10 procent. Spowolnienie możliwe do zmierzenia. Należy rozpocząć rejestrowanie dowodów i porównać te same godziny na przestrzeni kilku dni.
• Powyżej 10 procent przez wiele godzin. Węzeł jest przeciążony w stosunku do obciążenia. Jest to poziom uzasadniający zgłoszenie do pomocy technicznej lub migrację.

Powyższe przedziały należy traktować jako wskazówki interpretacyjne, a nie specyfikację, ponieważ żaden dostawca nie gwarantuje poziomu steal w planach współdzielonych. Należy oceniać je w kontekście uruchamianych zadań. Nocne zadanie wsadowe może tolerować 15 procent steal bez wpływu na działanie. Usługa wrażliwa na opóźnienia wykaże spadek wydajności w p99 znacznie wcześniej, zanim średnia zacznie budzić niepokój, dlatego obciążenia wrażliwe na opóźnienia, takie jak boty transakcyjne powinny działać na dedykowanych rdzeniach.

Ile kosztuje czas steal time?

Arytmetyka jest krótka. Jeśli ułamek s czasu procesora jest zajęty, zadanie wymagające określonej ilości czasu CPU trwa 1 / (1 - s) razy dłużej w czasie rzeczywistym. Dla zadania wymagającego 60 sekund czasu CPU:

[
  {
    "steal_percent": 0,
    "wall_clock_seconds": "60.0"
  },
  {
    "steal_percent": 3,
    "wall_clock_seconds": "61.9"
  },
  {
    "steal_percent": 8,
    "wall_clock_seconds": "65.2"
  },
  {
    "steal_percent": 15,
    "wall_clock_seconds": "70.6"
  },
  {
    "steal_percent": 25,
    "wall_clock_seconds": "80.0"
  },
  {
    "steal_percent": 40,
    "wall_clock_seconds": "100.0"
  }
]

Przy 3 procentach, co jest typowym odczytem dla planów współdzielonych, zadanie to trwa 61.9 sekund zamiast 60.0. Nikt nie zgłasza z tego powodu ticketu. Przy 8 procentach jest to 65.2 sekund. Przy 40 procentach to samo zadanie wymaga 100.0 sekund, a kolejka, która wcześniej była obsługiwana na bieżąco, zaczyna rosnąć.

Są to wartości obliczone, a nie pomiary. Model zakłada pojedynczy wątek gotowy do uruchomienia oraz równomierne rozłożenie czasu steal w całym interwale. Rzeczywiste usługi często działają gorzej, niż wskazywałaby na to krzywa, ponieważ skradziony wycinek czasu przypada w trakcie obsługi żądania, a opóźnienie jest następnie powielane przez wszystkie procesy oczekujące na to żądanie. Aby uzyskać własne dane zamiast korzystać ze wzoru, należy przeprowadzić benchmark VPS w godzinach niskiego obciążenia oraz ponownie w godzinach szczytu, rejestrując st dla obu tych okresów.

Czy to steal, czy coś innego?

Wskaźnik steal łatwo pomylić z innymi objawami. Należy analizować liczniki łącznie, w tej samej linii vmstat.

• st wysoki, podczas gdy r i us pozostają niskie: host nie przydziela czasu procesora. To jest steal.
• r znacznie powyżej liczby vCPU, przy wysokim us i st bliskim zeru: uruchomiono więcej zadań, niż dostępne procesory są w stanie przetworzyć. Porównaj r z wynikiem polecenia nproc. Jest to efekt własnego nadmiernego przydziału zasobów, a nie wpływ sąsiednich maszyn.
• wa wysoki, przy st bliskim zeru: zadania są blokowane przez operacje wejścia/wyjścia na nośnikach, co stanowi odrębny problem wymagający innego rozwiązania.
• Wysoki load average przy niskich wartościach st i us: wskaźnik obciążenia uwzględnia również zadania w stanie nieprzerywalnym, co zazwyczaj wskazuje na zawieszone urządzenie lub problem z montowaniem zasobów sieciowych, a nie na wyczerpanie zasobów CPU.

Plany typu burstable wymagają osobnego omówienia. Zapewniają one pulę kredytów, która rośnie w czasie bezczynności i maleje podczas pracy; po jej wyczerpaniu dostawca ogranicza wydajność do poziomu bazowego. Na niektórych platformach to ograniczenie jest raportowane jako steal. Na innych pozostaje niewidoczne z poziomu systemu operacyjnego, a użytkownik otrzymuje po prostu mniejszą liczbę cykli procesora na sekundę. Przed założeniem, że przyczyną problemów jest sąsiednia maszyna, należy zapoznać się z opisem planu taryfowego.

Dlaczego kontener nie raportuje czasu steal

Wartość steal jest właściwością maszyny wirtualnej, a nie kontenera działającego w jej wnętrzu. Kontener Docker na własnym VPS współdzieli /proc hosta, więc wartość st odczytana wewnątrz kontenera jest wartością steal dla VPS, co jest pożądanym zachowaniem. Wirtualizacja oparta na kontenerach, sprzedawana jako VPS, zachowuje się inaczej. Przy zastosowaniu lxcfs, wartość /proc/stat wewnątrz kontenera jest syntetyzowana na podstawie rozliczeń cgroup, a steal wynosi zero z definicji. Stos monitorujący, który pobiera dane tylko z wnętrza kontenera, może wykazywać płaskie, zerowe wartości, podczas gdy fizyczna maszyna poniżej jest przeciążona.

Wewnątrz kontenera licznik o tym samym znaczeniu to ograniczanie przydziału CPU (CPU quota throttling). W cgroup v2:

cat /sys/fs/cgroup/cpu.stat

nr_throttled zlicza okresy wymuszania, w których grupa osiągnęła swój limit CPU, a throttled_usec sumuje czas, w którym proces był wstrzymany. Rosnąca wartość nr_throttled oznacza, że proces był gotowy do pracy, ale nie był wykonywany – jest to doświadczenie tożsame ze steal, lecz spowodowane limitem ustawionym samodzielnie. Przed obwinieniem hosta należy sprawdzić własne limity, zwłaszcza jeśli uruchamiasz usługi w Docker na VPS z limitami CPU w pliku compose. Wirtualizacja warstwowa dodaje kolejne miejsce, w którym czas może znikać, ponieważ maszyna wirtualna wewnątrz VPS podlega zarówno wartości steal, jak i własnym opóźnieniom szeregowania. Należy o tym pamiętać, jeśli uruchamiasz zagnieżdżoną wirtualizację na VPS.

Co zrobić w przypadku utrzymującego się wskaźnika steal

Żadne ustawienie wewnątrz systemu gościa nie naprawi steal, ponieważ harmonogram podejmujący decyzje działa poza nim. Istnieją cztery realne kroki.

Najpierw zbierz dowody. Zapisz znaczniki czasu w UTC, czas trwania każdego epizodu, częstotliwość występowania oraz informację, czy mpstat wskazuje na jeden dotknięty vCPU, czy na wszystkie. Tydzień zarejestrowanych próbek jest wart więcej niż zrzut ekranu.

Otwórz zgłoszenie z tymi danymi. Zadaj dwa bezpośrednie pytania: czy węzeł jest przesycony w tych oknach czasowych oraz czy instancja może zostać przeniesiona. Wklej wynik vmstat oraz dokładne godziny. Dostawcy reagują na powtarzalne okna czasowe, a zgłoszenie zawierające jedynie informację o wolnym działaniu serwera spotka się z prośbą o dostarczenie dowodów. Ilość pracy, którą można przekazać dostawcy, stanowi jedną z praktycznych różnic między zarządzanym a niezarządzanym VPS.

Poproś o migrację. Przeniesienie gościa na mniej obciążony węzeł jest rutynową pracą dostawcy i zazwyczaj wymaga jedynie krótkiego restartu. Jest to rozwiązanie bezkosztowe, które rozwiązuje typowy przypadek, w którym jeden węzeł obsługuje jednocześnie kilku wymagających sąsiadów.

Wykup się od rywalizacji o zasoby. Plan z dedykowanym vCPU rezerwuje fizyczne rdzenie dla instancji, dzięki czemu licznik pozostaje na zerze. Kosztuje to więcej każdego miesiąca i jest uczciwą odpowiedzią dla obciążenia, które nie może tolerować wahań wydajności. Jeśli to nadal nie wystarcza lub wymagana jest wyłączność na przepustowość pamięci, kolejnym krokiem jest serwer dedykowany zamiast VPS.

W oczekiwaniu na rozwiązanie, ogranicz negatywny wpływ steal. Uruchamiaj mniej wątków roboczych niż posiadasz vCPU, ponieważ wątki, które nie mogą uzyskać dostępu do rdzenia, jedynie zwiększają liczbę przełączeń kontekstu. Przenieś zadania wsadowe na godziny, w których węzeł jest mniej obciążony, co wynika z prowadzonego logu. Następnie wykonaj ponowny pomiar za pomocą tego samego polecenia w tych samych godzinach, aby móc stwierdzić, czy zmiana zadziałała, zamiast zgadywać.

FAQ

Jaki poziom CPU steal time jest normalny na VPS?

W planach współdzielonych krótkie skoki oraz utrzymująca się wartość poniżej około 5 procent są zjawiskiem normalnym, ponieważ współdzielony procesor oznacza, że host dzieli fizyczne rdzenie między gości. Utrzymujące się przez wiele godzin wartości dwucyfrowe nie są normalne i stanowią podstawę do zgłoszenia problemu. W planie z dedykowanym vCPU oczekiwaną wartością jest 0.0, więc każda inna wartość jest błędem wymagającym zgłoszenia. Wartość tę należy oceniać w odniesieniu do własnego obciążenia: nocne zadania wsadowe mogą tolerować steal, którego nie zaakceptuje API wrażliwe na opóźnienia.

Czy większy plan rozwiąże problem wysokiego steal time?

Nie samodzielnie. Więcej vCPU na tym samym współdzielonym węźle oznacza więcej wirtualnych procesorów rywalizujących o te same obciążone fizyczne rdzenie, przez co odsetek ten może pozostać na tym samym poziomie. Tym, co eliminuje steal, jest przydział dedykowanego procesora lub przeniesienie na mniej obciążony węzeł. Większy udział w zasobach obciążonej maszyny to nadal udział w obciążonej maszynie.

Dlaczego mój VPS pokazuje 0 steal time, mimo że wyraźnie działa wolno?

Istnieją dwa częste powody. Hypervisor może w ogóle nie eksportować tego licznika, co jest typowe dla platform VMware i Hyper-V, przez co pole pozostaje na zerze niezależnie od działań hosta. Uruchom systemd-detect-virt, aby sprawdzić, na jakiej platformie działa serwer. W przeciwnym razie wąskie gardło znajduje się gdzie indziej: sprawdź wa pod kątem oczekiwania na operacje dyskowe, porównaj r z nproc w celu wykrycia własnego przeciążenia oraz sprawdź /sys/fs/cgroup/cpu.stat wewnątrz kontenerów pod kątem ograniczania przydziałów (throttling).

Czy mogę zmniejszyć steal time z poziomu mojego serwera?

Nie można zmienić harmonogramowania hosta z poziomu systemu gościa. Można jedynie ograniczyć negatywne skutki tego zjawiska. Uruchamiaj mniej wątków roboczych niż posiadasz vCPU, aby mniej zadań oczekiwało w kolejce na rdzeń, który nie jest dostępny. Przenieś zadania wsadowe na godziny, w których węzeł jest mniej obciążony. Stosuj buforowanie wyników, aby mniej zapytań wymagało użycia procesora. Zmiany, które faktycznie eliminują steal, takie jak migracja na inny węzeł lub dedykowane rdzenie, leżą po stronie dostawcy usług.