„Serverul e lent, hai să dublăm RAM-ul” e cel mai scump reflex din hosting. Uneori e corect. Adesea mașina așteaptă după disc sau CPU-ul e la maximum, iar memoria nouă stă acolo fără să facă nimic, în timp ce factura se dublează.
Așa că, înainte să vorbim despre cine are nevoie de 64 GB, hai să aflăm ce îți lipsește de fapt. Dacă vrei doar cifre tipice de memorie pentru fiecare sarcină, ghidul nostru anterior, De câtă memorie RAM are nevoie un VPS, le are, inclusiv formula pentru modelele de limbaj. Articolul de față e despre diagnostic: RAM, disc sau CPU.
Trei comenzi, două minute
Rulează-le pe serverul lent cât e lent, nu la 4 dimineața, când nu se întâmplă nimic:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Iată cum le citești fără manual.
free -m. Ignoră coloana free; Linux umple intenționat memoria nefolosită cu cache pentru disc. Uită-te la available. Dacă are câteva sute de megabyți pe o mașină de 2 GB, iar swap-ul used tot crește, memoria e strâmtă.
vmstat 1 10. Patru coloane spun cea mai mare parte a poveștii:
| Coloana | Ce înseamnă | Indică spre |
|---|---|---|
si / so | pagini aduse din swap și trimise în swap pe secundă | RAM |
wa | % din timp în care CPU-ul așteaptă după disc | disc |
us + sy | % din timp în care CPU-ul lucrează | CPU |
st | % din timp în care hypervisorul a dat CPU-ul tău altcuiva | CPU (vCPU împărțit) |
Câteva valori nenule în si/so din când în când sunt normale. Semnalul real e swap-ul constant, în fiecare secundă.
/proc/pressure/*. E cea mai cinstită dintre cele trei. Fiecare fișier arată ce parte din timp au stat sarcinile blocate, așteptând după resursa respectivă. some avg60=25.00 pe memory înseamnă că în ultimul minut ceva a stat blocat așteptând memoria un sfert din timp. Fișierul dintre cele trei cu cele mai mari cifre îți arată gâtul de sticlă.
Dacă e discul
wa mare, presiune mare pe io, puțin swap. Cauza obișnuită e o bază de date sau o aplicație care scrie multe loguri și citește mai mult decât încape în cache.
Iată întorsătura: mai mult RAM poate rezolva asta, pentru că Linux va pune în cache mai mult din disc. Dacă baza ta de date are 6 GB, iar partea fierbinte are 3 GB, trecerea de la 2 GB la 8 GB de memorie poate face problema discului să dispară. Dar dacă baza de date are 300 GB și fiecare interogare atinge altă parte a ei, nicio cantitate rezonabilă de RAM nu o va ține în cache. Atunci soluția sunt indecși mai buni, interogări mai mici sau altă organizare a datelor. Toate planurile de aici rulează pe NVMe, deci discul în sine e rar partea lentă. Tiparul de acces de obicei este.
Dacă e CPU-ul
us+sy mare, presiune pe cpu, fără swap, puțină așteptare după disc. Compresie, compilări, codare video, procesare de imagini, calcule criptografice. Mai multă memorie nu va ajuta deloc.
Urmărește și st. Pe un VPS, un vCPU e o parte dintr-un nucleu fizic, nu tot nucleul: numărul din plan e un plafon pentru rafale, iar sarcina maximă susținută poate fi limitată, ca lucrurile să rămână corecte pentru toți cei de pe mașină. Dacă sarcina ta are nevoie de toate nucleele la 100% ore întregi, e o problemă de sarcină, iar noi preferăm să spunem asta acum, nu după ce ai cumpărat un plan mai mare.
Dacă e chiar RAM-ul
Swap constant, presiune pe memorie în creștere, OOM killerul în dmesg. Acum întrebarea e cât.
2 GB ajung, adesea ani la rând, pentru: un bot sau câțiva, un API mic, un VPN, un site static în spatele Nginx, câteva scrapere în cron, un agent de monitorizare. Micro îți dă 2 vCPU, 2 GB și 25 GB pentru $5 pe lună pe NAT sau $10 cu propriul IPv4.
4–8 GB sunt mijlocul comod: o aplicație web plus baza ei de date, un index de căutare mic, automatizare cu browser headless, câțiva agenți care rulează unul lângă altul.
32–64 GB sunt pentru date care trebuie să stea în memorie:
- o bază de date al cărei set de lucru are zeci de gigabyți, ca cache-ul să țină de fapt datele fierbinți;
- un cache sau o coadă mare în memorie, care nu poate trece pe disc fără să încetinească totul;
- un index vectorial pentru căutare peste milioane de fragmente (vezi RAG găzduit de tine la scară pentru cifre reale);
- inferența doar pe CPU a unui model de limbaj de mărime medie, unde ponderile trebuie să încapă în RAM;
- consolidarea: zece servicii care stăteau înainte pe zece servere mici.
Pentru asta e Pro-64: 12 vCPU, 64 GB de RAM, 600 GB de NVMe și un IPv4 dedicat pentru $70 pe lună. Treptele dintre sunt Pro-32 cu $40 și Pro-48 cu $55; deasupra, Pro-80 cu $90. Toate planurile Pro rulează în UE.
Unde nu se potrivește o mașină mare
Trei cazuri în care 64 GB e răspunsul greșit, chiar dacă ți-l permiți.
Munca pe GPU. Niciunul dintre aceste planuri nu are GPU. Dacă modelul tău are nevoie de unul pentru antrenare sau inferență rapidă, o mașină cu CPU și mult RAM îl va rula, încet, iar tu vei plăti cu răbdare.
Sarcinile susținute pe tot CPU-ul. Ca mai sus: vCPU-urile sunt capacitate pentru rafale. Douăsprezece la 100% non-stop nu e ceva pentru care e construit un VPS.
Și „pentru orice eventualitate”. Dacă cele trei comenzi nu arată presiune pe memorie, cei 60 GB în plus sunt cache pentru fișiere pe care nu le citești. Începe mai mic. Trecerea la un plan mai mare cu același tip de rețea adaugă pe loc vCPU, RAM și disc, cu o singură repornire, cum e descris în Schimbarea planului. Micșorarea pe loc nu e posibilă, așa că a cumpăra prea mare are un cost real: ca să micșorezi, migrezi pe un server nou, iar mutarea unui VPS fără întrerupere e o corvoadă de care ai prefera să nu ai nevoie.
Dacă compari planuri de la mai mulți furnizori, cum citești specificațiile unui VPS explică ce promit de fapt cifrele de vCPU, disc și port.
Comentarii
Încă nu există comentarii. Fii primul.