Wolny VPS albo lagi? Tak znajdziesz przyczynę w 10 minut
Jeśli Twój VPS działa wolno, najpierw sprawdź, co właściwie jest wolne, a potem przejdź przez cztery miejsca: procesor (load, jeden rdzeń na 100 % albo steal time), pamięć (pełna, swap albo OOM-killer), dysk (iowait) i sieć (ping i utrata pakietów). Dzięki top, free, iostat i mtr w dziesięć minut wiesz, które z tych czterech hamuje.
Zainstaluj narzędzia zawczasu, wtedy będziesz mieć je pod ręką, gdy coś pójdzie nie tak:
sudo apt install htop sysstat mtr-tinyJeśli chcesz wykresów z dłuższego okresu, Netdata pokaże co sekundę, co robi Twój VPS. Na szybki rzut oka wystarczy też htop, jak w instrukcji sprawdzanie użycia zasobów VPS.
Wolny VPS? Najpierw ustal, co dokładnie działa wolno
„Wolno” może oznaczać trzy zupełnie różne rzeczy, a każda wskazuje gdzie indziej:
- Lagi w grze: gracze cofają się na wcześniejsze miejsce, zniszczone bloki pojawiają się z powrotem, pojazdy się przycinają. Zwykle serwer nie wyrabia ticków (procesor) albo połączenie gubi pakiety (sieć).
- Wolna sesja SSH: litery pojawiają się z opóźnieniem. To wskazuje na sieć albo na VPS tak zapchany, że nawet Twoja powłoka musi czekać.
- Wolna strona WWW: często baza danych albo dysk, czasem pamięć.
Zwróć też uwagę na wzorzec. Jest wolno zawsze, tylko wieczorem, gdy wszyscy są online, czy stale o tej samej porze? Stała pora często wskazuje na zaplanowane zadanie, takie jak Twój własny skrypt kopii zapasowych albo zadanie cron. I czy narzeka jeden gracz, czy wszyscy? Jeśli jeden gracz, zwykle chodzi o jego własne połączenie.

Procesor: load, jeden rdzeń na 100 % i steal time
Zacznij od dwóch liczb:
nproc
uptimenproc podaje liczbę Twoich vCore, uptime średnie obciążenie (load average) z 1, 5 i 15 minut. Jeśli load przez dłuższy czas przekracza liczbę vCore, praca czeka w kolejce. Linux wlicza w to też procesy czekające na dysk, więc potem sprawdź w top, co się dzieje. W top naciśnij 1, żeby zobaczyć każdy vCore osobno. Zwykle zobaczysz jeden z trzech wzorców:
- Wszystkie rdzenie pełne, z wysokimi wartościami przy
usisy: masz za mało mocy obliczeniowej albo jakiś proces się zapętlił. Sprawdź whtop, który proces jest na górze. - Jeden rdzeń na 100 %, reszta spokojna: klasyczny problem serwerów gier. Główny wątek Minecraft, FiveM czy Valheim dobił do sufitu. Więcej vCore wtedy nie pomoże, szybszy rdzeń tak. Dlaczego, przeczytasz w artykułach Co to jest vCore? i Ryzen czy EPYC na serwer gier?
- Wysokie
st: steal time, czyli czas, w którym hypervisor kazał Twojemu vCore czekać, bo fizyczny rdzeń pracował gdzie indziej. Kilka procent od czasu do czasu to norma przy współdzielonych vCore. Jeślistprzez dłuższy czas jest wyraźnie wysokie, a Twój serwer działa wolno, zapisz wynikvmstat 1 30i dołącz go do zgłoszenia; nasz support chętnie pomoże.
Pamięć: pełna, swap albo OOM-killer
free -hPatrz na kolumnę available, a nie na free. Linux wykorzystuje nieużywaną pamięć jako cache (buff/cache) i oddaje ją, gdy tylko jakiś program jej potrzebuje, więc niskie free to norma. Jeśli available jest bliskie zeru, pamięć naprawdę się skończyła. Potwierdzają to dwa sygnały:
- Swapowanie: w
vmstat 1kolumnysiisostale są powyżej zera. Twój VPS przerzuca pamięć na dysk i z powrotem, a odczuwasz to wszędzie. - OOM-killer: jądro zatrzymuje proces, gdy kończy się pamięć. Twój serwer gry wygląda wtedy, jakby padł bez komunikatu o błędzie. Sprawdzisz to poleceniem
sudo dmesg -T | grep -i -E 'out of memory|killed process'.
Częsty błąd przy serwerach w Javie: ustawienie -Xmx na całą pamięć VPS. Java zużywa więcej niż samą stertę, a system operacyjny też potrzebuje miejsca, więc zostaw co najmniej 1 GB wolnego. Jeśli uruchamiasz Minecraft z modami na mniej niż 8 GB, rozwiązaniem jest tu po prostu więcej pamięci.
Dysk: iowait i zaplanowane zadania
W top wartość wa oznacza czas, w którym procesor czeka, aż dysk skończy. Jeśli regularnie jest wysoka, sprawdź każdy dysk:
iostat -x 1Zwróć uwagę na r_await i w_await: średni czas w milisekundach, jaki trwa operacja odczytu lub zapisu, łącznie z czekaniem w kolejce. Na NVMe powinny być niskie; jeśli mocno rosną, jakiś proces zajmuje dysk. Kolumna %util przy NVMe mówi niewiele: według dokumentacji iostat przy urządzeniach obsługujących operacje równolegle nie pokazuje ich limitu. Który proces korzysta z dysku, zobaczysz w sudo iotop (pakiet iotop).
Typowi winowajcy to Twój własny skrypt kopii zapasowych albo zadanie cron, które pakuje cały katalog świata, plik logu rosnący bez ograniczeń i zapytanie do bazy bez indeksu. Sprawdź też poleceniem df -h, czy dysk nie jest pełny: pełny dysk powoduje dziwne błędy i zawieszenia, na długo zanim zorientujesz się, dlaczego.
Sieć: ping, mtr i utrata pakietów
Zmierz ze swojego komputera do VPS:
ping -c 20 twoje-ip
mtr -rwc 100 twoje-ipW Windows użyj ping -n 20 twoje-ip; zamiast mtr jest tam WinMTR. mtr wysyła 100 rund co sekundę i dla każdego przeskoku pokazuje utratę pakietów i opóźnienie. Czytaj to tak: utrata na przeskoku, która nie ciągnie się aż do ostatniej linii, zwykle pochodzi od routera, który daje pingom niski priorytet, i jest niegroźna. Utrata, która ciągnie się aż do Twojego VPS, jest prawdziwa. Jeśli narzeka jeden gracz, zmierz też z VPS do jego adresu IP.
Jeśli przycina się wszystkim graczom naraz, najpierw sprawdź na status.mc-node.net, czy coś się nie dzieje z węzłami. Wszystkie VPS stoją w Hengelo; jak odległość od Twoich graczy wpływa na ping, przeczytasz w artykule Lokalizacja serwera a ping.
Specyfika serwerów gier: TPS, MSPT i hitche
Serwer gry mierzy własną kondycję, a te liczby są często czytelniejsze niż top. Serwer Minecraft chce osiągać 20 ticków na sekundę, czyli maksymalnie 50 ms na tick (MSPT). Jeśli MSPT rośnie, a jeden rdzeń stoi na 100 %, winny jest procesor. Jeśli TPS i MSPT są w porządku, a laguje wszystkim, przyczyna leży raczej w sieci. Dla poszczególnych gier:
- TPS, MSPT i lagi: co naprawdę znaczą te liczby
- spark: jak sprawdzić, który plugin, encja albo chunk zjada czas
- Lagi na serwerze FiveM, o hitch warnings w konsoli i ciężkich skryptach
- Serwer Palworld: jak naprawić lagi i rubber-banding
Kiedy upgrade pomaga (a kiedy nie)
Większy pakiet rozwiązuje tylko to wąskie gardło, które znalazłeś:
| Co widzisz | Wąskie gardło | Co pomaga |
|---|---|---|
available bliskie zeru, swap albo komunikaty OOM | pamięć | większy pakiet w ramach Twojej linii |
| jeden rdzeń na 100 %, wysoki MSPT | szybkość jednego rdzenia | przejście z KVM VPS na Premium VPS albo rozprawienie się z ciężkimi pluginami i skryptami |
| wszystkie rdzenie pełne | moc obliczeniowa | więcej vCore albo rozłożenie obciążenia |
długotrwale wysokie st | współdzielone rdzenie | zgłoszenie z wynikiem vmstat albo VDS ze stałymi rdzeniami |
wysokie wa i await | obciążenie dysku | znalezienie i przeniesienie zadania; upgrade rzadko pomaga |
| utrata pakietów aż do ostatniego przeskoku | sieć | sprawdzenie strony statusu, dołączenie wyniku mtr; upgrade nie pomoże |
W ramach swojej linii przechodzisz na większy pakiet w panelu klienta i dopłacasz różnicę za resztę okresu rozliczeniowego. Jeśli wąskim gardłem jest szybkość jednego rdzenia, logicznym krokiem jest Premium VPS z Ryzen 9: AMD Ryzen 9 9950X* z DDR5, do 5,7 GHz wobec do 4,0 GHz w EPYC 7443P w KVM VPS. Jeśli to steal time, zobacz VDS ze stałymi rdzeniami. Przejście między liniami nie odbywa się jednym kliknięciem: nastaw się na nowy VPS i przeprowadzkę. Jeśli nie wiesz, która linia pasuje, przeczytaj Jaki serwer VPS wybrać?
* lub AMD Ryzen 9 7950X3D, zależnie od węzła.
Najczęściej zadawane pytania
Dlaczego mój VPS działa wolno?
Zwykle przez jedno z czterech wąskich gardeł: procesor (jeden rdzeń na 100 % albo steal time), pamięć (pełna albo swapowanie), dysk (dużo iowait przez jakiś proces albo pełny dysk) lub sieć (utrata pakietów). Dzięki top, free -h, iostat -x 1 i mtr w dziesięć minut zobaczysz, które to. Serwer gier z lagami często ma wąskie gardło procesora w głównym wątku.
Co to jest steal time i czy to źle?
Steal time (st w top) to czas, w którym Twój vCore chciał liczyć, ale hypervisor oddał fizyczny rdzeń innemu VPS. Kilka procent od czasu do czasu to norma przy współdzielonych vCore. Jeśli przez dłuższy czas jest wysoki, a serwer działa wolno, dołącz do zgłoszenia wynik vmstat 1 30 albo wybierz VDS ze stałymi rdzeniami.
Czy więcej RAM pomoże na lagi?
Tylko jeśli pamięć naprawdę jest pełna: available w free -h jest bliskie zeru, Twój VPS swapuje albo OOM-killer zatrzymuje procesy. Lagów przez główny wątek, który utknął na jednym rdzeniu, nie rozwiążesz większą ilością RAM; wtedy pomaga szybszy rdzeń albo lżejsze pluginy i skrypty.
Jak sprawdzić, czy jest awaria?
Zajrzyj na status.mc-node.net; tam jest status węzłów na żywo. Jeśli nic tam nie widać, a przycina się tylko Twój serwer, poszukaj przyczyny za pomocą top, free, iostat i mtr. Gdy otwierasz zgłoszenie, dołącz wynik mtr ze swojego komputera.