„Serwer zwalnia, podwójmy RAM” to najdroższy odruch w hostingu. Czasem trafny. Często jednak maszyna czeka na dysk albo procesor jest zajęty do granic, a nowa pamięć leży bezczynnie, podczas gdy rachunek rośnie dwukrotnie.
Zanim więc porozmawiamy o tym, komu potrzebne jest 64 GB, sprawdźmy, czego ci naprawdę brakuje. Jeśli chcesz tylko typowych liczb pamięci dla różnych zadań, znajdziesz je w naszym wcześniejszym poradniku Ile RAM potrzebuje VPS, łącznie ze wzorem dla modeli językowych. Ten tekst jest o diagnozie: RAM, dysk czy CPU.
Trzy polecenia, dwie minuty
Uruchom je na wolnym serwerze, kiedy jest wolny, a nie o czwartej rano, gdy nic się nie dzieje:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Oto jak je czytać bez podręcznika.
free -m. Zignoruj kolumnę free; Linux celowo wypełnia wolną pamięć cache dysku. Patrz na available. Jeśli na maszynie z 2 GB jest tam kilkaset megabajtów, a used w swapie ciągle rośnie, pamięci jest na styk.
vmstat 1 10. Cztery kolumny mówią większość:
| Kolumna | Co oznacza | Wskazuje na |
|---|---|---|
si / so | strony wczytywane i zapisywane do swapu na sekundę | RAM |
wa | % czasu, gdy CPU czeka na dysk | dysk |
us + sy | % czasu, gdy CPU pracuje | CPU |
st | % czasu, gdy hypervisor oddał twój CPU komuś innemu | CPU (vCPU dzielony z innymi) |
Kilka niezerowych wartości si/so od czasu do czasu to norma. Prawdziwy sygnał to stałe swapowanie, sekunda po sekundzie.
/proc/pressure/*. Najuczciwszy z trzech. Każdy plik pokazuje, przez jaką część czasu zadania stały w oczekiwaniu na dany zasób. some avg60=25.00 w memory oznacza, że w ostatniej minucie coś przez jedną czwartą czasu czekało na pamięć. Plik z największymi liczbami wskazuje twoje wąskie gardło.
Jeśli to dysk
Wysokie wa, wysoka presja na io, mało swapowania. Typowa przyczyna to baza danych albo aplikacja z masą logów, która czyta więcej, niż mieści się w cache.
A teraz zwrot akcji: więcej RAM może to naprawić, bo Linux zbuforuje więcej dysku. Jeśli twoja baza ma 6 GB, a jej gorąca część 3 GB, przejście z 2 GB na 8 GB pamięci może sprawić, że problem z dyskiem zniknie. Ale jeśli baza ma 300 GB i każde zapytanie dotyka innej jej części, żadna rozsądna ilość RAM jej nie zbuforuje. Wtedy pomogą lepsze indeksy, mniejsze zapytania albo inny układ danych. Wszystkie taryfy tutaj działają na NVMe, więc wolny rzadko bywa sam dysk. Zwykle wolny jest sposób dostępu do niego.
Jeśli to CPU
Wysokie us+sy, presja na cpu, brak swapowania, mało czekania na dysk. Kompresja, buildy, kodowanie wideo, obróbka obrazów, obliczenia kryptograficzne. Więcej pamięci nic tu nie da.
Obserwuj też st. Na VPS vCPU to część czasu fizycznego rdzenia, a nie cały rdzeń: liczba w taryfie to sufit dla krótkich skoków, a długotrwałe pełne obciążenie może być ograniczane, żeby było uczciwie dla wszystkich na maszynie. Jeśli twoje zadanie potrzebuje wszystkich rdzeni na 100% godzinami, to kwestia samego zadania, i wolimy powiedzieć to teraz niż po tym, jak kupisz większą taryfę.
Jeśli to naprawdę RAM
Stałe swapowanie, rosnąca presja na pamięć, OOM killer w dmesg. Teraz pytanie brzmi: ile.
2 GB wystarcza, często latami, na: jednego bota albo kilka, małe API, VPN, statyczną stronę za Nginx, kilka scraperów z crona, agenta monitoringu. Micro daje 2 vCPU, 2 GB i 25 GB za 5 $ miesięcznie na NAT albo za 10 $ z własnym IPv4.
4–8 GB to wygodny środek: aplikacja webowa razem z bazą, mały indeks wyszukiwania, automatyzacja przeglądarki w trybie headless, kilku agentów obok siebie.
32–64 GB to miejsce dla danych, które muszą żyć w pamięci:
- baza, której zbiór roboczy to dziesiątki gigabajtów, żeby cache naprawdę trzymał gorące dane;
- duży cache albo kolejka w pamięci, które nie mogą zejść na dysk bez spowolnienia wszystkiego;
- indeks wektorowy do wyszukiwania w milionach fragmentów (prawdziwe liczby w artykule Własny RAG na dużą skalę);
- inferencja średniej wielkości modelu językowego na CPU, gdzie wagi muszą zmieścić się w RAM;
- konsolidacja: dziesięć usług, które wcześniej żyły na dziesięciu małych serwerach.
Do tego właśnie służy Pro-64: 12 vCPU, 64 GB RAM, 600 GB NVMe i dedykowany IPv4 za 70 $ miesięcznie. Szczeble pośrednie to Pro-32 za 40 $ i Pro-48 za 55 $; wyżej Pro-80 za 90 $. Dostępność lokalizacji dla taryf Pro widać przy zamówieniu.
Gdzie duża maszyna się nie sprawdzi
Trzy przypadki, w których 64 GB to zła odpowiedź, nawet jeśli cię na nie stać.
Praca na GPU. Żadna z tych taryf nie ma GPU. Jeśli twój model potrzebuje go do trenowania albo szybkiej inferencji, maszyna z CPU i dużą ilością RAM go uruchomi, ale powoli, i zapłacisz za cierpliwość.
Długotrwałe zadania na pełnym CPU. Jak wyżej: vCPU to zasób na skoki. Dwanaście sztuk na 100% przez całą dobę to nie to, do czego zbudowano VPS.
I „na wszelki wypadek”. Jeśli trzy polecenia nie pokazują presji na pamięć, dodatkowe 60 GB to cache dla plików, których nie czytasz. Zacznij od mniejszego. Przejście na większą taryfę tego samego typu sieci dodaje vCPU, RAM i dysk na miejscu, z jednym restartem, jak opisano w dziale Zmiana taryfy. W dół na miejscu się nie da, więc zbyt duży zakup ma realny koszt: żeby się zmniejszyć, przenosisz się na nowy serwer, a przeniesienie VPS bez przestoju to praca, której wolałbyś uniknąć.
Jeśli porównujesz taryfy różnych dostawców, artykuł Jak czytać parametry VPS wyjaśnia, co naprawdę obiecują liczby dotyczące vCPU, dysku i portu.
Komentarze
Brak komentarzy. Bądź pierwszy.