Dimensioner de app die je daadwerkelijk draait.

Voordat je meet

Gebruik een Linux testmachine die je beheert, met je applicatie en representatieve data. De onderstaande commando's inspecteren resources; ze tunen de kernel niet en verwijderen geen bestanden. Je hebt procps en GNU coreutils nodig, en toestemming om de gekozen applicatiemap te inspecteren. Vervang /srv/my-app door het echte pad. Als de app nog nergens draait, gebruik dan de ontwikkel- of stagingomgeving om een eerste schatting te maken en herzie die schatting later op het beoogde systeem.

Schrijf op wat de VPS deelt: besturingssysteem, proxy, API, database, workers en monitoring. Leg vast of asset-builds daar draaien, of back-ups lokaal worden gecomprimeerd, en of een geplande taak kan overlappen met een deployment. Een rustig applicatieproces kan samengaan met een duur releaseproces.

Lees beschikbaar geheugen en identificeer de processen

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m rapporteert mebibytes. Focus op available, de schatting van geheugen dat nieuw werk kan ondersteunen zonder te swappen; free sluit op zichzelf nuttig vrijmaakbaar geheugen uit. Cache is daarom op zichzelf geen reden om meer RAM te kopen. Zie de vrije velddefinities.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

De proces-RSS-waarden hierboven komen ruwweg overeen met 384, 180 en 32 MiB. Ze helpen om geheugengebruik te lokaliseren, maar het optellen van elke RSS-waarde is geen exact machinetotaal: gedeelde pagina's kunnen meerdere keren worden geteld en sommige kernelkosten vallen buiten de proceswaarde. Vermijd het afdrukken van commandoregels of omgevingen bij het verzamelen van een rapport, omdat ze secrets kunnen bevatten. De ps-handleiding legt de velden en het snapshot-gedrag uit.

Zet observaties om in een werkblad

De volgende budgetten illustreren een kleine API met een lokale database en één worker. Het zijn verzonnen planningswaarden, geen benchmarks of minimale vereisten voor een bepaald framework. Vervang ze door je eigen metingen en noteer welke budgetten tegelijkertijd kunnen pieken.

Dit werkblad overschrijdt al een budget van 1,024 MiB. Een testomgeving van 2,048 MiB zou 676 MiB overlaten tegen deze budgetten, maar het nuttige resultaat is of echte representatieve belasting past terwijl de app responsief blijft. Als het deploymentbudget domineert, kan artefacten elders bouwen een betere wijziging zijn dan de permanente server vergroten. Bewaar de aannames naast het totaal.

Let op CPU en swap tijdens nuttig werk

vmstat 1 10

Voer dit uit tijdens een representatieve reeks verzoeken, een job en een release. Negeer de eerste regel bij het interpreteren van een recent interval: deze vat activiteit sinds het opstarten samen. Latere regels beschrijven de meetintervallen. Aanhoudend uitvoerbaar werk in r, lage idle-tijd in id en trage verzoeken samen rechtvaardigen onderzoek naar CPU-druk. Herhaalde si/so activiteit toont swapping; alleen toegewezen swap bewijst geen huidige druk. wa en st hebben context nodig in plaats van een automatische CPU-upgrade. Deze velden zijn gedefinieerd in vmstat.

Registreer ook de responstijd op applicatieniveau. Een langzame externe API of databasequery kan verzoeken laten wachten terwijl de CPU grotendeels idle blijft. Herhaal dezelfde workload na één wijziging, zodat je weet welke wijziging hielp. Belastingstests mogen alleen gericht zijn op systemen die je beheert, met een tempo en stopconditie die andere gebruikers niet verstoren.

Budgetteer schijfgroei en overdracht apart

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df beschrijft het bestandssysteem dat het pad bevat, inclusief ruimte die met andere mappen wordt gedeeld; df -i controleert inodegebruik waar ondersteund. Een groot aantal kleine bestanden kan inodes uitputten vóór de bytecapaciteit. du schat de gekozen map, afhankelijk van toegangsrechten. Dit zijn verschillende vragen, dus hun totalen hoeven niet overeen te komen. Zie df en du.

Maak een lijst van de huidige database, uploads, logs, applicatie-artefacten en eventuele lokale back-upstagingruimte. Voeg de ruimte toe die nodig is voor een release naast de vorige release en schat vervolgens de groei over het volgende controle-interval. Bijvoorbeeld, 100 MiB aan nieuwe uploads per dag voegt ongeveer 3,000 MiB toe over 30 dagen vóór replica's of back-ups. Label decimale GB en binaire GiB consistent bij het vergelijken van het resultaat met een catalogus.

Voor overdracht is een illustratieve respons van 20 kB die 50,000 keer wordt verzonden ongeveer 1 GB aan responspayload. Voeg uploads, statische bestanden, protocoloverhead en back-upverkeer toe. Die berekening schat volume, niet doorvoer of gelijktijdige gebruikers. Bevestig hoe de service verkeer telt en omgaat met eventuele overschrijdingen.

Kies de volgende actie en controleer deze

• Laag beschikbaar geheugen tijdens normale pieken: inspecteer de belangrijkste verbruikers en test een groter geheugenbudget.
• Trage verzoeken met aanhoudende CPU-druk: profileer het drukke pad en vergelijk vervolgens CPU-wijzigingen met dezelfde workload.
• Groeiend schijfgebruik: identificeer de verantwoordelijke map en het bewaarbeleid voordat je iets verwijdert.
• Resources lijken comfortabel maar de app is traag: onderzoek afhankelijkheden, queries en het verzoekpad.

Bewaar het werkblad met de workloadbeschrijving, meettijd, eenheden en volgende controledatum. Controleer opnieuw na een substantiële release, datagroei of een toegevoegde worker. Kies een configuratie op basis van die observaties; geen enkele plannaam garandeert verzoekcapaciteit. Ga verder met het lezen van waarschuwingen over geheugen en schijf of het eerste API-resourcescenario.