Benennen Sie die Arbeit, bevor Sie den Host wählen
Zeichnen Sie den Anforderungspfad: Reverse-Proxy, API-Prozess, Datenbank und externe Dienste. Fügen Sie den asynchronen Pfad hinzu: Warteschlange, Worker und Exportziel. Halten Sie fest, welche Komponenten den Host gemeinsam nutzen, wer die Parallelität steuert und welche Daten einen Neuaufbau überleben müssen. Sie benötigen Anwendungsmetriken und eine Nicht-Produktions-Workload mit repräsentativen Daten; diese Anleitung setzt keine bereitgestellte PrivacyNodes-Instanz voraus.
Für eine beispielhafte Reporting-API liest eine HTTP-Anfrage Kontoeinstellungen und reiht einen Export ein. Der Worker durchsucht Zeilen und schreibt eine Datei. Eine schnelle Einreihungsantwort beweist nicht, dass der Export während des Spitzenverkehrs abgeschlossen werden kann. Beziehen Sie geplante Bereinigung und Deployment-Überlappung in den Testplan ein.
Beziehen Sie Überlappung in das Speicher-Arbeitsblatt ein
Dies sind hypothetische Planungseingaben in MiB, keine Messungen oder Zusicherungen über PrivacyNodes. Ersetzen Sie sie durch beobachtete Anwendungsanforderungen. RSS umfasst residente gemeinsame Mappings; das Addieren des RSS jedes Prozesses kann Speicher doppelt zählen. Der verfügbare Speicher des Hosts ist nützlicher, als den gesamten Dateisystem-Cache als dauerhaft nicht verfügbar zu behandeln.
Technische Referenz: Linux Prozess-Speicher-Abrechnung.
| Komponente | Budget | Annahme |
|---|---|---|
| Host und Tooling | 512 MiB | OS, Proxy, Telemetrie |
| Zwei API-Prozesse | 768 MiB | 384 je bei angenommenem Spitzenwert |
| Ein Export-Worker | 512 MiB | Begrenzte Batches |
| Datenbank | 1,024 MiB | Cache- und Abfragearbeit |
| Release-Überlappung | 512 MiB | Alte und neue Arbeit koexistieren |
| Nicht zugewiesene Marge | 512 MiB | Unsicherheit zu untersuchen |
| Gesamtannahme | 3,840 MiB | Mit tatsächlichem Host-Speicher vergleichen |
Dies ist zu nahe an einer nominellen 4 GB-Hülle, um komfortable Kapazität anzunehmen. Prüfen Sie den tatsächlich vom Host gemeldeten Speicher und ob sich Spitzen überlappen. Reduzieren Sie die Parallelität, verschieben Sie eine Komponente oder fügen Sie Speicher hinzu; entfernen Sie nicht die Reserve, nur damit die Tabelle passt.
PostgreSQL work_mem ist eine Zuweisung pro Vorgang, kein Gesamtdatenbanklimit. Gleichzeitige Sitzungen und Vorgänge können ihre Wirkung vervielfachen. Docker-Container haben standardmäßig keine CPU- oder Speicherbeschränkungen; ein Image ist keine Ressourcenrichtlinie.
Technische Referenz: PostgreSQL-Ressourcenverbrauch · Docker-Ressourcenbeschränkungen.
Messen Sie CPU zusammen mit dem Warteschlangenalter
Testen Sie eine gewöhnliche Anfrage, den langsamsten nützlichen Bericht, eine fehlgeschlagene Abhängigkeit und einen Export zusammen. Zeichnen Sie Latenz-Perzentile, Fehler, Host-CPU, Worker-Parallelität und Alter des ältesten Jobs über dasselbe Intervall auf. CPU-Druck bei Warteschlangenwachstum legt eine andere Aktion nahe als niedrige CPU bei langer Datenbankwartezeit.
Beginnen Sie das Beispiel mit einem laufenden Export. Wenn der Worker auf externen Speicher wartet, kann zusätzliche CPU wenig ändern. Wenn er wiederholt einen Kern sättigt, während die API-Latenz steigt, testen Sie einen kleineren Export-Batch oder ein separates Worker-Budget. Ändern Sie einen Faktor und wiederholen Sie dasselbe Szenario, bevor Sie Kapazität kaufen.
Budgetieren Sie die nächste Wartungsoperation
Listen Sie Datenbankdateien und Indizes, Uploads, Logs, temporäre Exporte, Release-Artefakte und freien Speicher für Wartung auf. Notieren Sie das Wachstum pro Woche und wann Ihre Reserve erschöpft wäre. Ein 20 GB-Datensatz plus eine 20 GB-temporäre Kopie benötigt mehr als 20 GB, selbst wenn der gewöhnliche Anwendungsverkehr ruhig ist.
Weisen Sie Log-Rotation und Export-Ablauf zu. Bewahren Sie Wiederherstellungskopien außerhalb der Fehlergrenze des Hosts auf. Zusätzlicher VPS-Speicher erweitert die Arbeitszuweisung; eine Kopie auf derselben Festplatte ist kein unabhängiges Backup. Testen Sie sowohl den Normalbetrieb als auch ein Release, das parallel zu einem Backup oder Export läuft.
Schreiben Sie eine Entscheidung, die überprüft werden kann
Ihre Ausgabe ist ein Arbeitsblatt, eine Workload-Beschreibung und ein Überprüfungsauslöser: wachsendes Alter des ältesten Jobs während des repräsentativen Tests, schrumpfender Wartungsplatz oder ein Release, das nicht mit aktuellen Prozessen koexistieren kann. Zeichnen Sie Beobachtungen auf, anstatt einen universellen CPU-Prozentschwellenwert zu erfinden.
Vergleichen Sie App 2 und Scale 4 gegen diese Einschränkungen. Wenn das Ergebnis Sie immer noch überrascht, verfolgen Sie eine langsame Anfrage durch den Stack. Diese Übung schätzt Ihre Workload; sie etabliert keinen Lieferanten-Benchmark, keine Verkehrskapazität oder Verfügbarkeit.
Offizielle Referenzen
Die Dokumentation wurde für diesen Artikel überprüft. Beispiele sind Planungsübungen, keine auf einem PrivacyNodes-Server getesteten Befehle. Prüfen Sie die Dokumentation für Ihre installierte Version.