Dimensionieren Sie die App, die Sie tatsächlich betreiben.

Bevor du misst

Verwende eine von dir kontrollierte Linux-Testmaschine mit deiner Anwendung und repräsentativen Daten. Die folgenden Befehle untersuchen Ressourcen; sie optimieren nicht den Kernel und löschen keine Dateien. Du benötigst procps und GNU coreutils sowie die Berechtigung, das gewählte Anwendungsverzeichnis zu untersuchen. Ersetze /srv/my-app durch seinen tatsächlichen Pfad. Wenn die App noch nirgends läuft, verwende ihre Entwicklungs- oder Staging-Umgebung, um eine erste Schätzung zu erstellen, und überprüfe diese Schätzung dann auf dem vorgesehenen System.

Notiere, was sich den VPS teilt: Betriebssystem, Proxy, API, Datenbank, Worker und Monitoring. Halte fest, ob Asset-Builds dort laufen, ob Backups lokal komprimiert werden und ob eine geplante Aufgabe ein Deployment überlappen kann. Ein ruhiger Anwendungsprozess kann mit einem teuren Release-Prozess koexistieren.

Verfügbaren Speicher lesen und die Prozesse identifizieren

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

free -m meldet Mebibytes. Konzentriere dich auf available, die Schätzung des Speichers, der neue Arbeit ohne Swapping unterstützen könnte; free allein schließt nützlichen rückgewinnbaren Speicher aus. Cache ist daher für sich genommen kein Grund, mehr RAM zu kaufen. Siehe die Definitionen der free-Felder.

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

Die obigen RSS-Werte der Prozesse entsprechen ungefähr 384, 180 und 32 MiB. Sie helfen, die Speichernutzung zu lokalisieren, aber das Addieren jedes RSS-Werts ergibt keine exakte Maschinensumme: Gemeinsam genutzte Seiten können mehrfach gezählt werden und einige Kernel-Kosten liegen außerhalb der Prozesszahl. Vermeide beim Erstellen eines Berichts das Ausgeben von Kommandozeilenargumenten oder Umgebungen, da sie Geheimnisse enthalten können. Das ps-Handbuch erklärt seine Felder und das Snapshot-Verhalten.

Beobachtungen in ein Arbeitsblatt überführen

Die folgenden Ansätze veranschaulichen eine kleine API mit lokaler Datenbank und einem Worker. Sie sind erfundene Planungswerte, keine Benchmarks oder Mindestanforderungen für ein bestimmtes Framework. Ersetze sie durch deine Messungen und notiere, welche Ansätze gleichzeitig spitzen können.

Dieses Arbeitsblatt überschreitet bereits ein Budget von 1,024 MiB. Eine 2,048 MiB Testumgebung würde 676 MiB gegenüber diesen Ansätzen lassen, aber das nützliche Ergebnis ist, ob echte repräsentative Arbeit passt, während die App reaktionsfähig bleibt. Wenn der Deployment-Ansatz dominiert, könnte das Erstellen von Artefakten an anderer Stelle eine bessere Änderung sein als das Vergrößern des permanenten Servers. Bewahre die Annahmen neben der Summe auf.

CPU und Swap während nützlicher Arbeit beobachten

vmstat 1 10

Führe dies während eines repräsentativen Anfrage-Batches, eines Jobs und eines Releases aus. Ignoriere bei der Interpretation eines aktuellen Intervalls die erste Zeile: Sie fasst die Aktivität seit dem Booten zusammen. Spätere Zeilen beschreiben die Abtastintervalle. Anhaltend ausführbare Arbeit in r, niedrige Leerlaufzeit in id und langsame Anfragen zusammen rechtfertigen eine Untersuchung des CPU-Drucks. Wiederholte si/so Aktivität zeigt Swapping; allein zugewiesener Swap beweist keinen aktuellen Druck. wa und st benötigen Kontext statt eines automatischen CPU-Upgrades. Diese Felder sind definiert in vmstat.

Zeichne auch die Antwortzeit an der Anwendung auf. Eine langsame externe API oder Datenbankabfrage kann Anfragen warten lassen, während die CPU größtenteils im Leerlauf bleibt. Wiederhole dieselbe Arbeitslast nach einer Änderung, damit du weißt, welche Änderung geholfen hat. Lasttests sollten nur auf Systeme abzielen, die du kontrollierst, mit einer Rate und Abbruchbedingung, die andere Nutzer nicht stören.

Festplattenwachstum und Transfer getrennt budgetieren

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

df beschreibt das Dateisystem, das den Pfad enthält, einschließlich des mit anderen Verzeichnissen gemeinsam genutzten Speichers; df -i prüft die Inode-Nutzung, wo unterstützt. Eine große Anzahl kleiner Dateien kann Inodes vor der Byte-Kapazität erschöpfen. du schätzt den gewählten Baum, abhängig von Zugriffsberechtigungen. Dies sind unterschiedliche Fragen, daher müssen ihre Summen nicht übereinstimmen. Siehe df und du.

Liste die aktuelle Datenbank, Uploads, Logs, Anwendungsartefakte und jeden lokalen Backup-Staging-Speicher auf. Füge den für ein Release benötigten Speicher neben dem vorherigen Release hinzu und schätze dann das Wachstum über das nächste Überprüfungsintervall. Zum Beispiel fügen 100 MiB neuer Uploads pro Tag etwa 3,000 MiB über 30 Tage vor Replikaten oder Backups hinzu. Kennzeichne dezimale GB und binäre GiB konsistent, wenn du das Ergebnis mit einem Katalog vergleichst.

Für den Transfer sind eine illustrativ 20 kB Antwort, 50,000 Mal gesendet, etwa 1 GB Antwortnutzlast. Füge Uploads, statische Dateien, Protokoll-Overhead und Backup-Verkehr hinzu. Diese Arithmetik schätzt das Volumen, nicht den Durchsatz oder gleichzeitige Nutzer. Bestätige, wie der Dienst den Verkehr zählt und mit Überschuss umgeht.

Die nächste Aktion wählen und prüfen

• Niedriger verfügbarer Speicher während normaler Spitzen: Untersuche die Hauptverbraucher und teste ein größeres Speicherbudget.
• Langsame Anfragen mit anhaltendem CPU-Druck: Profiling des stark belasteten Pfads, dann vergleiche CPU-Änderungen mit derselben Arbeitslast.
• Wachsende Festplattennutzung: Identifiziere das verantwortliche Verzeichnis und die Aufbewahrungsrichtlinie, bevor du etwas löschst.
• Ressourcen scheinen komfortabel, aber die App ist langsam: Untersuche Abhängigkeiten, Abfragen und den Anfragepfad.

Speichere das Arbeitsblatt mit der Arbeitslastbeschreibung, Abtastzeit, Einheiten und dem nächsten Überprüfungsdatum. Überprüfe erneut nach einem wesentlichen Release, Datenwachstum oder einem hinzugefügten Worker. Wähle eine Konfiguration aus diesen Beobachtungen; kein Planname garantiert Anforderungskapazität. Fahre fort mit Speicher- und Festplattenwarnungen lesen oder dem ersten API-Ressourcen-Szenario.