Co oznacza CPU steal time na VPS i jak go sprawdzić

Co faktycznie mierzy CPU steal time

CPU steal time to część czasu, w którym 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 przez inny proces. Linux zlicza te cykle oddzielnie i raportuje je jako st. Dzięki temu można 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 tego 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, jest raportowany jako wa (I/O wait). vCPU, który jest gotowy do pracy, znajduje się w kolejce uruchomieniowej, nie oczekuje na operacje I/O, a mimo to nie wykonuje instrukcji, jest raportowany jako st. Żaden proces wewnątrz serwera nie może zmienić tego stanu, ponieważ decyzja o szeregowaniu zadań zapada warstwę niżej, na hoście.

Wynika to bezpośrednio z sposobu współdzielenia jednej maszyny fizycznej przez VPS 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 przyczyna, często pomijana. Wielu dostawców ogranicza współdzielony vCPU do ułamka fizycznego rdzenia, a w przypadku wielu hypervisorów to wymuszone ograniczenie jest zliczane wewnątrz gościa 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ć wartości steal, ponieważ nie ma wglądu w stan hosta. Informację tę przekazuje hiperwizor. W środowisku KVM host zapisuje licznik dla każdego vCPU na stronie 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żdym jądrze dystrybucyjnym). Xen raportuje te same dane poprzez obszar runstate. Łączna 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 to ósma liczba po etykiecie. Wszystkie poniższe narzędzia, vmstat, top, mpstat oraz każdy eksporter Prometheus, odczytują to samo pole i na podstawie dwóch próbek obliczają wartość procentową.

Jedna konsekwencja jest istotniejsza od pozostałych. Jeśli hiperwizor nie eksportuje licznika, pole to pozostaje na stałe równe zero, a każde narzędzie oparte na tym odczycie będzie raportować stan 0.0, nawet jeśli host jest przeciążony. KVM i Xen eksportują tę wartość. Systemy gości na VMware i Hyper-V zazwyczaj raportują stałe zero. Przed zaufaniem odczytowi 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, takie jak 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 zapewnia odpowiednie zasoby. Na platformie, która nie wypełnia tego pola, zero nie stanowi żadnego dowodu, a o rywalizacji o zasoby należy wnioskować na podstawie pomiarów czasu wykonywania rzeczywistych zadań.

Jak sprawdzić czas steal CPU na VPS?

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

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

vmstat --version wyświetla linię taką jak vmstat from procps-ng 4.0.4. Jeśli wynik się pojawi, narzędzie jest zainstalowane i odczytuje rzeczywiste liczniki jądra. vmstat 1 5 pobiera następnie 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

Znajdź kolumnę st w bloku cpu po prawej stronie. Aktualne kompilacje procps-ng wyświetlają po niej kolumnę gu dla czasu gościa KVM, więc 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 pozwalają na rzetelną interpretację wyników. Pierwsza linia danych to średnia od momentu uruchomienia systemu, dlatego należy ją zignorować i czytać kolejne linie. Jedna próbka nie stanowi pomiaru, ponieważ czas steal występuje w skokach: uruchom vmstat 1 60 i obserwuj przez pełną minutę przed wyciągnięciem wniosków.

top raportuje tę samą wartość w linii 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, dodaj sysstat:

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

mpstat drukuje jeden wiersz na CPU z kolumną %steal, która pokazuje, czy problem dotyczy każdego vCPU, czy tylko jednego. Aby uzyskać historię potrzebną do zgłoszenia technicznego, zapisuj próbki do pliku zamiast odczytywać je z ekranu:

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

Uruchom to polecenie przez cron w godzinach, w których występują podejrzenia, a plik stanie się dowodem, który pozwoli uniknąć zgłoszenia typu „działało wolno w nocy” na rzecz wskazania dostawcy dokładnych dziesięciu minut występowania problemu.

Co oznaczają wartości steal?

• Stałe 0.0. Stan prawidłowy lub platforma nie raportuje wartości steal. Przed wyciągnięciem wniosków należy potwierdzić to za pomocą systemd-detect-virt.
• Kilkuprocentowe skoki trwające sekundy. Zjawisko normalne na każdym współdzielonym węźle. Może wynikać z rozpoczęcia procesu budowania przez sąsiedni serwer lub wykonywania kopii zapasowych przez hosta.
• Utrzymujące się na poziomie 1 do 5 procent w planach współdzielonych. Stan oczekiwany. Cena odzwierciedla współdzielony charakter procesora.
• Utrzymujące się na poziomie 5 do 10 procent. Mierzalne spowolnienie. Należy rozpocząć gromadzenie danych i porównać te same godziny w ciągu kilku dni.
• Powyżej 10 procent przez wiele godzin. Węzeł jest nadmiernie obciążony w stosunku do realizowanego zadania. Jest to poziom uzasadniający zgłoszenie do wsparcia technicznego lub migrację.

Powyższe zakresy należy traktować jako wskazówkę interpretacyjną, a nie specyfikację, ponieważ żaden dostawca nie gwarantuje określonego 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 odczucia użytkowników. Usługa wrażliwa na opóźnienia wykaże spadek wydajności w statystykach p99 na długo przed tym, zanim średnia wartość stanie się alarmująca, dlatego obciążenia wrażliwe na opóźnienia, takie jak boty transakcyjne powinny być uruchamiane 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 potrzebują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ż wskazuje na to krzywa, ponieważ skradziony wycinek czasu przypada w środku żą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, wykonaj 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 oraz us pozostają niskie: host nie przydziela czasu procesora. To jest steal.
• r znacznie powyżej liczby vCPU, przy wysokim us i st bliskim zeru: obciążenie przekracza możliwości własnych procesorów. Porównaj r z wynikiem 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 podsystem pamięci masowej, co stanowi odrębny problem wymagający innego rozwiązania.
• Wysoki load average przy niskich wartościach st oraz us: wskaźnik obciążenia uwzględnia również zadania w stanie nieprzerywalnym, co zazwyczaj wskazuje na zawieszone urządzenie lub problem z montowaniem sieciowym, a nie na brak zasobów CPU.

Plany typu burstable wymagają osobnego omówienia. Zapewniają one pulę kredytów, która rośnie w czasie bezczynności i wyczerpuje się podczas pracy; po jej zużyciu 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 odnotowuje jedynie mniejszą liczbę cykli 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 w niej uruchomionego. Kontener Docker na własnym VPS współdzieli /proc hosta, więc wartość st odczytana wewnątrz kontenera jest wartością steal dla całego VPS, co jest pożądanym zachowaniem. Wirtualizacja oparta na kontenerach, sprzedawana jako VPS, działa inaczej. Przy zastosowaniu lxcfs, wartość /proc/stat wewnątrz kontenera jest syntetyzowana na podstawie rozliczeń cgroup, a steal wynosi z założenia zero. Stos monitorujący, który pobiera dane tylko z wnętrza kontenera, może wykazywać płaskie, zerowe wartości, podczas gdy fizyczna maszyna pod spodem 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. Wzrost wartości 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.

Jak reagować na utrzymujący się wskaźnik steal

Żadne ustawienie wewnątrz systemu gościa nie naprawi problemu steal, ponieważ harmonogram zadań podejmujący decyzje działa poza nim. Aktualizacja jądra również nie przyniesie zmiany: mechanizm cache aware scheduling dodany w Linux kernel 7.2 jedynie zmienia rozmieszczenie zadań na rdzeniach, które faktycznie zostały przydzielone, i nie odzyska cykli procesora zajętych już przez sąsiednie instancje. Istnieją cztery realne kroki.

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

Otwórz zgłoszenie z tymi danymi. Zadaj dwa bezpośrednie pytania: czy węzeł jest przeciążony w tych przedziałach czasowych oraz czy instancja może zostać przeniesiona. Wklej wynik vmstat oraz dokładne godziny występowania problemu. Dostawcy reagują na powtarzalne okna czasowe; zgłoszenie z ogólną informacją o wolnym działaniu serwera spotka się jedynie z prośbą o dostarczenie szczegółów. Zakres pracy, którą można scedować na dostawcę, 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ą czynnością dla dostawcy i zazwyczaj wymaga jedynie krótkiego restartu. Jest to rozwiązanie bezkosztowe, które sprawdza się w typowych przypadkach, gdy na jednym węźle znajduje się jednocześnie kilka obciążających sąsiednich instancji.

Wyeliminuj rywalizację o zasoby poprzez zakup. Plan z dedykowanymi vCPU rezerwuje fizyczne rdzenie dla instancji, dzięki czemu licznik steal pozostaje na poziomie zero. Wiąże się to z wyższym miesięcznym kosztem, ale jest uczciwym rozwiązaniem dla obciążeń, które nie tolerują zmiennoś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 pomiar ponownie za pomocą tego samego polecenia w tych samych godzinach, aby móc stwierdzić, czy zmiana przyniosła efekt, zamiast opierać się na domysłach.

FAQ

Jaka wartość CPU steal time jest normalna na serwerze VPS?

W planach współdzielonych krótkotrwałe skoki oraz utrzymująca się wartość poniżej około 5 procent są zjawiskiem typowym, ponieważ współdzielenie procesora oznacza, że host dzieli fizyczne rdzenie między gości. Utrzymujące się przez wiele godzin dwucyfrowe wartości nie są normalne i stanowią podstawę do zgłoszenia problemu. W planach z dedykowanym vCPU oczekiwaną wartością jest 0.0, więc każda inna wartość oznacza błąd wymagający zgłoszenia. Ocenę wartości należy odnieść do własnego obciążenia: nocne zadania wsadowe tolerują opóźnienia, których nie zaakceptuje API wrażliwe na czas odpowiedzi.

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 rdzenie fizyczne, przez co procentowa wartość może pozostać bez zmian. Problem steal time eliminuje przydział dedykowanego procesora lub przeniesienie na mniej obciążony węzeł. Większy udział w zasobach przeciążonej maszyny nadal pozostaje udziałem w przeciąż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, dlatego pole pozostaje na poziomie zero 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 limitó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 cache, aby mniej zapytań wymagało użycia procesora. Zmiany, które faktycznie eliminują steal time, czyli migracja na inny węzeł lub dedykowane rdzenie, leżą po stronie dostawcy usług.