Limits und Ressourcen
Limits und Ressourcen
Pro Dienst zugewiesene Ressourcen
| Ressource | Garantiertes Minimum | Obergrenze |
|---|---|---|
| CPU | 50 m (0,05 Kern) | 1 Kern |
| Speicher | 64 MB | 512 MB |
Diese Obergrenzen decken die große Mehrheit der Anwendungsfälle ab. Wenn Ihre Anwendung mehr benötigt (aufwendige Verarbeitung, umfangreicher Build), kontaktieren Sie den Support für eine Anpassung.
Speicher
- Anwendungsdienste: das Dateisystem ist flüchtig. Alles, was auf die Festplatte geschrieben wird, verschwindet beim Neustart oder Redeployment des Pods. Speichern Sie dort niemals zu bewahrende Daten.
- Datenbanken: persistenter Speicher über ein Kubernetes-Volume (PVC). Die Daten überstehen Neustarts, Updates und Migrationen.
Datenbanken
Ein Datenbankdienst erhält eine größere Zuteilung als ein Anwendungsdienst, und sein Speicher ist persistent:
| Ressource | Garantiertes Minimum | Obergrenze |
|---|---|---|
| CPU | 100 m (0,1 Kern) | 1 Kern |
| Arbeitsspeicher | 256 MB | 1 GB |
Verwaltete Datenbanken und das Kontingent des Plans
Es gibt zwei Wege zu einer Datenbank, mit zwei Zählregeln:
- Verwaltete Datenbank (MySQL oder PostgreSQL, erstellt auf der Seite Datenbanken): Sie läuft auf den gemeinsamen Datenbankservern der Plattform und wird nicht auf vCPU und Arbeitsspeicher Ihres Plans angerechnet. Sie hat eigene Grenzen: mit einem bezahlten Abonnement bis zu 10 Datenbanken mit je 10 GB und 50 gleichzeitigen Verbindungen; ohne Abonnement eine Datenbank mit 500 MB und 10 Verbindungen.
- Datenbank als Dienst in einem Projekt (Container mit MySQL, MariaDB, PostgreSQL, MongoDB oder Redis): ein Dienst wie jeder andere. Sie verbraucht vCPU, Arbeitsspeicher und Speicher Ihres Plans, innerhalb der Grenzen der Tabelle oben.
Die Ressourcen eines Plans (vCPU, Arbeitsspeicher, Speicher, Traffic) bilden ein gemeinsames Budget für alle Dienste, die er abdeckt: Ein Plan mit unbegrenzten Diensten erlaubt beliebig viele Dienste, innerhalb desselben Budgets.
Build
- maximale Build-Dauer: 1 Stunde. Danach wird der Build gestoppt und das Deployment als fehlgeschlagen markiert. Ein Build, der dieses Limit erreicht, hängt fast immer (ein Entwicklungsserver anstelle des Build-Befehls gestartet, ein Skript, das auf eine Eingabe wartet);
- empfohlene Image-Größe: weniger als 2 GB, für schnelle Deployments;
- Builds verbrauchen nicht die Ressourcen Ihrer Dienste: sie laufen in einer separaten Umgebung mit eigener Zuteilung.
Netzwerk
- jeder Dienst wird über HTTPS auf seiner/seinen Domain(s) exponiert;
- keine künstliche Grenze bei der Anzahl gleichzeitiger Verbindungen;
- die verfügbare Bandbreite hängt vom abgeschlossenen Plan ab.
Verfügbarkeit
Die Infrastruktur strebt eine Verfügbarkeit von 99,5 % an, ohne vertragliche Zusage. Geplante Wartungsarbeiten werden im Voraus auf der Statusseite angekündigt.