Overprovisioning – dlaczego Twój VPS nie daje mocy, za którą płacisz

W skrócie: Overprovisioning (oversubscription) to sprzedaż przez dostawcę większej liczby wirtualnych rdzeni (vCPU) niż jest fizycznych rdzeni w serwerze. Gdy sąsiednie maszyny na tym samym hoście obciążają procesor, Twój VPS czeka w kolejce do rdzenia – a to opóźnienie widać jako „steal time” (%st). Efekt: płacisz za moc, której nie dostajesz w szczycie. Ten przewodnik pokazuje, jak to rozpoznać, zmierzyć i wymusić gwarancję zasobów.

Znasz to: VPS ma „4 vCPU i 8 GB RAM”, monitoring pokazuje, że procesor jest w połowie wolny, a mimo to aplikacja mieli się wolno, zapytania do bazy się ślimaczą, a użytkownicy narzekają. Zasoby na papierze są. Mocy nie ma. W większości takich przypadków winowajca jest jeden i ma nazwę: overprovisioning.

Ten artykuł tłumaczy mechanizm bez owijania w bawełnę, daje Ci konkretne komendy do samodzielnej diagnozy i pokazuje, jakich zapisów szukać w umowie, żeby nie płacić za moc widmową.

Co to jest overprovisioning (oversubscription) u dostawcy VPS

Zjawisko, o którym mówimy, ma w polskim obiegu dwie nazwy i jedną definicję: to przydzielenie klientom sumarycznie więcej zasobów wirtualnych, niż fizycznie istnieje w serwerze-hoście. W dokumentacji technicznej nazywa się to oversubscription (formalnie także overcommitment, potocznie nadsprzedaż). W cennikach hostingowych i na forach przyjęło się mówić „overprovisioning” i tak też brzmi tytuł tego tekstu, bo tak ludzie tego szukają. W FAQ na końcu wyjaśniamy, dlaczego ściśle rzecz biorąc to dwa różne pojęcia i o co dopytać dostawcę, żeby nie było nieporozumień. Najczęściej dotyczy procesora (vCPU), ale występuje też na RAM (memory ballooning, swap), przepustowości sieci i operacjach dyskowych (IOPS).

Mechanizm opiera się na statystyce: dostawca zakłada, że nie wszyscy klienci obciążą swoje maszyny w tym samym momencie. Fizyczny host z 32 rdzeniami może więc mieć sprzedane 100, 150, a w budżetowych ofertach nawet 200 vCPU. Dopóki obciążenie jest rozłożone w czasie, każdy dostaje tyle, ile potrzebuje. Problem zaczyna się w szczycie – gdy kilka maszyn naraz chce liczyć.

vCPU to nie rdzeń – skąd bierze się różnica

To fundamentalne nieporozumienie w zakupie VPS. vCPU nie jest gwarancją fizycznego rdzenia – to jednostka rozliczeniowa i harmonogramowa. Hypervisor (KVM, VMware, Hyper-V) przydziela czas fizycznego rdzenia kolejnym vCPU według swojego schedulera. Jeśli rdzeni fizycznych jest mniej niż aktywnych vCPU, część maszyn musi poczekać na swoją turę.

Dodatkowo w grę wchodzi hyper-threading: procesor z 16 rdzeniami fizycznymi raportuje 32 wątki logiczne. Wielu dostawców liczy vCPU od wątków, nie od rdzeni – a wątek logiczny to nie to samo co pełny rdzeń, zwłaszcza pod obciążeniem obliczeniowym.

Kiedy overprovisioning jest normą, a kiedy patologią

Uczciwie: umiarkowany oversubscription to standard branży i sam w sobie nie jest oszustwem. Środowiska deweloperskie, testowe czy strony o zmiennym ruchu naprawdę nie potrzebują dedykowanego rdzenia przez 24 godziny na dobę – i nie chcą za niego płacić. Model współdzielony obniża cenę i to jest legalna, sensowna wymiana.

Patologia zaczyna się w trzech sytuacjach:

1. Ratio jest ekstremalne (np. 10:1 lub więcej vCPU na rdzeń fizyczny) i host regularnie się dławi.

2. Dostawca to ukrywa – sprzedaje „4 vCPU” jako równoważnik czterech rdzeni, nie informując o współdzieleniu.

3. Obciążenie jest stałe i produkcyjne – baza danych, ERP, system transakcyjny – a mimo to trafia na mocno przesprzedany host.

Granica przebiega tam, gdzie kończy się przewidywalność. Jeśli nie wiesz, ile mocy dostaniesz jutro w godzinach szczytu, płacisz za loterię.

Dlaczego VPS zwalnia, mimo że „zasoby są wolne”

Najbardziej mylący objaw: top pokazuje 40-50% użycia CPU, a aplikacja i tak stoi. Dzieje się tak, bo klasyczne metryki obciążenia (us, sy, id) mierzą, co robi Twój system – a nie to, jak długo Twój system czekał na dostęp do fizycznego rdzenia, który akurat liczył zadania sąsiada.

To opóźnienie ma osobny licznik. W maszynach wirtualnych na Linuksie nazywa się steal time i pokazuje się jako %st w top, vmstat czy mpstat. W świecie VMware odpowiednikiem jest metryka CPU Ready (czas, przez który vCPU było gotowe do pracy, ale musiało czekać na fizyczny rdzeń).

Kolejka do rdzenia, czyli czym naprawdę jest steal time

Najprościej wyobrazić to sobie jako kolejkę do rdzenia. Twój VPS podchodzi do okienka (fizycznego rdzenia), ale przed nim stoi kilka innych maszyn z tego samego hosta. Steal time to czas, przez który stoisz w tej kolejce – jesteś gotów pracować, masz zadania, ale hypervisor oddał rdzeń komuś innemu. To zjawisko nazywa się też efektem hałaśliwego sąsiada (noisy neighbor).

Kluczowe: steal time nie obciąża Twojego rachunku za CPU, bo Twój procesor formalnie „nic nie robił” – on czekał. Dlatego overprovisioning jest tak trudny do wykrycia standardowym monitoringiem, który patrzy na użycie, a nie na czekanie. Efekt biznesowy jest jednak realny: dłuższy czas odpowiedzi, timeouty, kolejkująca się baza danych i użytkownicy, którzy odchodzą.

Objawy, przyczyny i pomiar – tabela diagnostyczna

Jak sprawdzić, czy Twój dostawca overprovisionuje – krok po kroku

Sekcja HowTo (oznaczyć schema HowTo). Poniższe komendy działają na typowym VPS z Linuksem. Uruchamiaj je na maszynie testowej lub w oknie, gdy ewentualne obciążenie nie zaszkodzi produkcji.

Krok 1 – Zmierz steal time (test podstawowy).

Uruchom vmstat 1 10 i obserwuj kolumnę st. Wartości utrzymujące się powyżej 0 oznaczają, że Twój VPS czeka na rdzeń. Interpretacja praktyczna:

• %st blisko 0 – dostęp do rdzenia bez rywalizacji (dobrze);
• %st 1-5% – lekki, okresowy oversubscription (akceptowalne dla wielu zastosowań);
• %st powyżej 10% utrzymujące się – tracisz realną moc, ale przyczyny mogą być dwie: przeciążony host albo limit CPU nałożony na Twój własny plan.

Jak je odróżnić. Steal wynikający z limitu Twojego planu (instancje burstable, twarde quoty cgroups) jest równy i powtarzalny: pojawia się zawsze po przekroczeniu przydziału i trzyma stały poziom. Steal od sąsiadów faluje – rośnie w godzinach szczytu, znika w nocy, ma nieregularny kształt. Dlatego krok 4, czyli pomiar w oknie 24-48 godzin, jest ważniejszy niż pojedynczy odczyt. O tym, z czym masz do czynienia, mówi kształt wykresu, a nie wartość chwilowa.

Dla obrazu w czasie użyj mpstat -P ALL 1, żeby zobaczyć steal per rdzeń.

Uwaga krytyczna: ten pomiar działa tylko na KVM i Xen. Licznik steal time to mechanizm zegara paravirtualizowanego, który hypervisor musi udostępnić maszynie gościa. Robią to KVM i Xen, czyli platformy stojące pod większością tanich VPS-ów. Na VMware i Hyper-V %st pokaże zero nawet wtedy, gdy host jest ciężko przeciążony. Odpowiednikiem jest tam metryka CPU Ready, widoczna w esxtop lub vCenter, czyli po stronie administratora hosta, a nie Twojej.

Sprawdź więc najpierw, na czym stoisz: systemd-detect-virt albo lscpu i pole „Hypervisor vendor”. Jeśli wynik to VMware lub Microsoft, pomiń krok 1 i przejdź od razu do kroku 2. Benchmark porównawczy o różnych porach doby to jedyna metoda, która działa niezależnie od platformy wirtualizacji i jedyna, do której nie potrzebujesz dostępu do hosta. Jest też trudniejsza do zakwestionowania przez dostawcę, bo mierzy skutek, a nie mechanizm.

Krok 2 – Zrób benchmark CPU o różnych porach.

Zainstaluj sysbench i uruchom test jednordzeniowy oraz wielordzeniowy, np. sysbench cpu –cpu-max-prime=20000 –threads=1 run, a potem –threads=4. Zapisz wynik (events/s). Powtórz test w godzinach nocnych i w szczycie (np. 10:00 i 19:00). Duża różnica wyników między porami to najmocniejszy dowód oversubscriptionu – Twoja maszyna się nie zmienia, zmienia się tylko obciążenie sąsiadów.

Krok 3 – Przetestuj dysk (IOPS i latencja).

Uruchom fio z testem losowego odczytu. Pełna, działająca komenda:

`

fio –name=test –filename=testfile –size=1G –rw=randread –bs=4k –iodepth=32 –direct=1 –ioengine=libaio –runtime=60 –time_based

`

Kluczowy jest przełącznik –direct=1. Bez niego test przechodzi przez pamięć podręczną systemu i mierzy wydajność RAM-u, a nie dysku: dostaniesz wynik rzędu setek tysięcy IOPS i wniosek, że wszystko jest w porządku. Po teście skasuj plik testfile.

Uzyskane IOPS i latencję porównaj z tym, co obiecuje oferta. „NVMe” w cenniku nie znaczy nic, jeśli macierz jest współdzielona i przesprzedana – liczy się gwarantowany IOPS.

Krok 4 – Sprawdź stabilność w oknie 24-48 h.

Ustaw prosty cron zbierający %st i wynik krótkiego sysbench co 15 minut. Po dobie masz wykres, który pokazuje, czy spadki mocy są przypadkowe, czy cykliczne (a cykliczne = przewidywalny szczyt = przesprzedany host).

Krok 5 – Skonfrontuj wyniki z ofertą i umową.

Jeśli benchmarki rozjeżdżają się z tym, co kupiłeś, masz twarde dane do rozmowy z dostawcą – albo do zmiany dostawcy na takiego, który gwarantuje zasoby.

Jak się chronić – gwarantowane vCPU, SLA i zapisy w umowie

Diagnoza to połowa sukcesu. Druga połowa to niedopuszczenie do problemu przy zakupie. Na co patrzeć:

1. Gwarantowane (dedykowane) vCPU. Szukaj oferty, w której vCPU jest przypisane do fizycznego rdzenia/wątku i nie jest współdzielone. To zwykle droższe od budżetowego VPS – i o to chodzi. Płacisz za pewność mocy, nie za loterię.

2. Jawny współczynnik oversubscription. Uczciwy dostawca powie Ci, jaki stosuje ratio, albo wprost zadeklaruje jego brak dla danej klasy usług. Brak odpowiedzi na to pytanie jest odpowiedzią.

3. SLA obejmujące wydajność, nie tylko dostępność. Standardowe SLA gwarantuje „99,9% uptime” – czyli że maszyna jest włączona. To nie to samo co gwarancja, że ma moc. Pytaj o parametry wydajnościowe (gwarantowany IOPS, brak steal time).

4. Prawo do benchmarku i wyjścia. Zapis umożliwiający weryfikację parametrów i rozwiązanie umowy, jeśli nie są dotrzymane, zamienia obietnicę marketingową w zobowiązanie.

5. Izolacja zasobów, nie tylko wirtualizacja. Dopytaj, czy dostawca stosuje limity (cgroups) i rezerwacje CPU/RAM per maszyna – to one chronią Cię przed hałaśliwym sąsiadem.

Jeśli obciążenie jest stałe, produkcyjne i krytyczne, warto rozważyć krok dalej – serwer dedykowany (bare metal), gdzie fizyczny sprzęt jest w całości Twój. 

Podejście Engave – VPS bez overprovisioningu

W Engave projektujemy VPS z gwarantowanymi zasobami – vCPU i RAM są przypisane do maszyny, a nie współdzielone w loterii. To decyzja architektoniczna, nie hasło z cennika: w klasie usług z gwarantowanymi zasobami nie stosujemy oversubscriptionu w ogóle. vCPU jest przypisane do wątku fizycznego, RAM zarezerwowany, bez ballooningu. Klient produkcyjny musi wiedzieć, ile mocy dostanie w każdej godzinie doby, a nie ile dostanie średnio.

Dane z benchmarków Engave:

• Na naszych maszynach z gwarantowanym vCPU %st utrzymuje się poniżej 1%, a rozrzut wyniku sysbench między nocą a szczytem mieści się w granicach kilku procent, czyli w szumie pomiarowym. To nie jest deklaracja marketingowa, tylko konsekwencja architektury: przy zasobach przypisanych do wątku fizycznego nie ma z kim rywalizować o rdzeń.
• Nie publikujemy natomiast uśrednionych pomiarów „u konkurencji”. Każdy taki wynik zależy od tego, na który host trafiła akurat maszyna testowa, a my nie wiemy, czy trafiliśmy na typowy, czy na najgorszy – i nikt tego nie wie. Zamiast liczby oddajemy Ci metodę z sekcji powyżej: zmierz swój obecny VPS przez dobę i porównaj wynik z naszą deklaracją. To jedyny benchmark, który cokolwiek dla Ciebie znaczy.

Do tego dochodzą pozostałe zasady engavecloud.pl: stałe, jawne ceny, brak dopłat za transfer danych (egress), wsparcie L2 24/7 w cenie oraz dane w Polsce (polska jurysdykcja, zgodność z RODO/NIS2). Kontekst kosztów rozkładamy w materiale Ile kosztuje VPS dla firmy, a szerzej model chmury omawiamy w przewodniku Chmura prywatna dla firm.

Jeśli interesuje Cię, jak gwarancja zasobów łączy się z odpornością danych, zajrzyj do bazy wiedzy o Cyfrowym Bunkrze i cyber recovery na engave.pl.

FAQ

Czym różni się overprovisioning od oversubscription?

W ścisłej terminologii wirtualizacji to nie synonimy, tylko dwie przeciwstawne praktyki.

Oversubscription (overcommitment, nadsprzedaż) to przydzielenie sumarycznie większej liczby zasobów, niż fizycznie jest w hoście – jak overbooking w liniach lotniczych. To zjawisko opisuje ten artykuł.

Overprovisioning w dokumentacji Red Hata i VMware oznacza sytuację odwrotną: celowy zapas mocy ponad realne zapotrzebowanie, czyli przewymiarowanie środowiska. Kosztuje więcej, niż trzeba, ale nie odbiera nikomu wydajności.

W polskim obiegu potocznym słowo „overprovisioning” przykleiło się do nadsprzedaży i w tym znaczeniu funkcjonuje w ofertach oraz w tytule tego tekstu. Jeśli jednak rozmawiasz z dostawcą o zapisach w umowie, nie używaj żadnego z tych słów. Zapytaj wprost o stosunek liczby sprzedanych vCPU do liczby fizycznych rdzeni na hoście. Tego sformułowania nie da się zinterpretować na dwa sposoby.

Czy overprovisioning zawsze jest szkodliwy?

Nie. Umiarkowany oversubscription obniża cenę usług, które nie potrzebują stałej mocy (dev, test, strony o zmiennym ruchu). Szkodliwy staje się, gdy ratio jest ekstremalne, host regularnie się dławi, a dostawca ukrywa fakt współdzielenia przy obciążeniu produkcyjnym.

Jak szybko sprawdzić, czy mój VPS ma steal time?

Uruchom vmstat 1 10 i spójrz na kolumnę st, albo top i pole %st. Wartości powyżej kilku procent, utrzymujące się w czasie, oznaczają, że maszyna czeka na dostęp do fizycznego rdzenia.

Jaki poziom steal time jest akceptowalny?

Orientacyjnie: poniżej 1% to bardzo dobrze, 1-5% bywa akceptowalne dla wielu zastosowań, powyżej 10% utrzymujące się to sygnał, że tracisz realną moc na przesprzedanym hoście. Ostatecznie liczy się, czy aplikacja mieści się w swoich wymaganiach czasu odpowiedzi.

Czy więcej vCPU rozwiąże problem wolnego VPS?

Zwykle nie. Jeśli źródłem jest steal time, dodanie vCPU na tym samym przesprzedanym hoście tylko wydłuża kolejkę do rdzenia. Rozwiązaniem jest gwarancja zasobów, nie ich nominalne zwiększenie na papierze.

Czy steal time występuje na serwerze dedykowanym (bare metal)?

Nie. Na serwerze dedykowanym cały fizyczny procesor jest Twój, więc nie ma z kim rywalizować o rdzeń – %st pozostaje zerowy. To główny argument za bare metal przy stałym, ciężkim obciążeniu.

Jak overprovisioning wygląda na środowiskach VMware?

Odpowiednikiem steal time jest metryka CPU Ready – czas, przez który vCPU było gotowe do pracy, ale musiało czekać na fizyczny rdzeń. Wysokie CPU Ready (mierzone w esxtop lub vCenter) to ten sam sygnał rywalizacji o zasoby.

Czy dostawca musi ujawnić współczynnik oversubscription?

Nie ma takiego powszechnego obowiązku, dlatego to Ty powinieneś o niego zapytać przed podpisaniem umowy. Uczciwy dostawca poda ratio lub zadeklaruje gwarantowane zasoby dla danej klasy usługi na piśmie.

Chcesz sprawdzić, czy Twój obecny VPS oddaje moc, za którą płacisz? Umów bezpłatną konsultację techniczną VPS Engave Cloud – przejdziemy przez wyniki Twoich pomiarów, wskażemy, gdzie tracisz wydajność na przesprzedanym hoście, i pokażemy, jak wygląda VPS z gwarantowanymi zasobami. Bez zobowiązań.