„De server is traag, laten we het RAM verdubbelen” is de duurste reflex in hosting. Soms klopt hij. Vaak wacht de machine op de schijf, of zit de CPU vol, en ligt het nieuwe geheugen er werkloos bij terwijl de rekening verdubbelt.
Dus voordat we het hebben over wie 64 GB nodig heeft, zoeken we eerst uit wat je echt tekortkomt. Wil je alleen typische geheugengetallen per workload, dan staan die in onze eerdere gids Hoeveel RAM heeft een VPS nodig, inclusief de formule voor taalmodellen. Dit stuk gaat over diagnose: RAM, schijf of CPU.
Drie commando's, twee minuten
Draai ze op de trage server terwijl hij traag is, niet om vier uur 's nachts als er niets gebeurt:
free -m
vmstat 1 10
cat /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io
Zo lees je ze zonder handboek.
free -m. Negeer de kolom free; Linux vult vrij geheugen expres met schijfcache. Kijk naar available. Staat daar op een machine met 2 GB maar een paar honderd megabyte en blijft used bij swap groeien, dan wordt het krap.
vmstat 1 10. Vier kolommen vertellen het grootste deel van het verhaal:
| Kolom | Wat het betekent | Wijst op |
|---|---|---|
si / so | pagina's per seconde in en uit swap | RAM |
wa | % van de tijd dat de CPU op de schijf wacht | schijf |
us + sy | % van de tijd dat de CPU werkt | CPU |
st | % van de tijd dat de hypervisor je CPU aan een ander gaf | CPU (vCPU gedeeld met anderen) |
Af en toe een paar waarden boven nul bij si/so is normaal. Het echte signaal is constant swappen, seconde na seconde.
/proc/pressure/*. De eerlijkste van de drie. Elk bestand toont welk deel van de tijd taken stillagen in afwachting van die resource. some avg60=25.00 bij memory betekent dat er de afgelopen minuut een kwart van de tijd iets op geheugen wachtte. Het bestand met de hoogste getallen is je knelpunt.
Als het de schijf is
Hoge wa, hoge io-druk, weinig swappen. De gebruikelijke oorzaak is een database of een app met veel logging die meer leest dan in de cache past.
En dan de wending: meer RAM kan dit oplossen, omdat Linux dan meer van de schijf cachet. Is je database 6 GB en het hete deel 3 GB, dan kan de stap van 2 naar 8 GB geheugen het schijfprobleem laten verdwijnen. Is de database 300 GB en raakt elke query een ander deel, dan cachet geen redelijke hoeveelheid RAM dat. Dan helpen betere indexen, kleinere queries of een andere opzet van de data. Alle tarieven hier draaien op NVMe, dus de schijf zelf is zelden het trage deel. Het toegangspatroon meestal wel.
Als het de CPU is
Hoge us+sy, cpu-druk, geen swappen, weinig wachten op de schijf. Compressie, builds, videocodering, beeldbewerking, cryptografisch rekenwerk. Meer geheugen helpt hier helemaal niet.
Let ook op st. Op een VPS is een vCPU een deel van de tijd van een fysieke core, niet de hele core: het getal in het tarief is een plafond voor pieken, en langdurige volle belasting kan worden afgeknepen om het eerlijk te houden voor iedereen op de machine. Heeft je taak urenlang alle cores op 100 % nodig, dan is dat een kwestie van de workload, en dat zeggen we liever nu dan nadat je een groter tarief hebt gekocht.
Als het echt het RAM is
Constant swappen, oplopende geheugendruk, de OOM-killer in dmesg. Nu is de vraag: hoeveel.
2 GB is genoeg, vaak jarenlang, voor: één of een paar bots, een kleine API, een VPN, een statische site achter Nginx, een paar cron-scrapers, een monitoringagent. Micro geeft je 2 vCPU, 2 GB en 25 GB voor $5 per maand op NAT, of $10 met een eigen IPv4.
4–8 GB is het comfortabele midden: een webapp met zijn database, een kleine zoekindex, headless browserautomatisering, een paar agents naast elkaar.
32–64 GB is voor data die in het geheugen moet leven:
- een database met een werkset van tientallen gigabytes, zodat de cache de hete data echt vasthoudt;
- een grote in-memory cache of queue die niet naar schijf kan uitwijken zonder alles te vertragen;
- een vectorindex voor zoeken over miljoenen fragmenten (echte cijfers in Self-hosted RAG op schaal);
- CPU-inferentie van een middelgroot taalmodel, waarbij de gewichten in het RAM moeten passen;
- consolidatie: tien diensten die vroeger op tien kleine servers draaiden.
Daar is Pro-64 voor: 12 vCPU, 64 GB RAM, 600 GB NVMe en een dedicated IPv4 voor $70 per maand. De tussenstappen zijn Pro-32 voor $40 en Pro-48 voor $55; daarboven Pro-80 voor $90. Welke locaties beschikbaar zijn voor de Pro-tarieven, zie je bij het bestellen.
Waar een grote machine niet past
Drie gevallen waarin 64 GB het verkeerde antwoord is, ook als je het kunt betalen.
GPU-werk. Geen van deze tarieven heeft een GPU. Heeft je model er een nodig voor training of snelle inferentie, dan draait een CPU-machine met veel RAM het wel, maar traag, en dan betaal je voor geduld.
Langdurige taken op volle CPU. Zoals hierboven: vCPU's zijn piekcapaciteit. Twaalf ervan dag en nacht op 100 % is niet waar een VPS voor gebouwd is.
En „voor de zekerheid”. Laten de drie commando's geen geheugendruk zien, dan zijn die extra 60 GB cache voor bestanden die je niet leest. Begin kleiner. Overstappen op een groter tarief van hetzelfde netwerktype voegt vCPU, RAM en schijf ter plekke toe, met één herstart, zoals beschreven in Tarief wijzigen. Kleiner gaan kan niet ter plekke, dus te groot kopen kost echt geld: om te krimpen migreer je naar een nieuwe server, en een VPS verhuizen zonder downtime is een klus die je liever niet nodig hebt.
Vergelijk je tarieven van verschillende aanbieders, dan legt VPS-specificaties lezen uit wat de getallen voor vCPU, schijf en poort echt beloven.
Reacties
Nog geen reacties. Wees de eerste.