Grenzwerte und Kontingente für Code Engine

Die folgenden Abschnitte enthalten technische Details zu den Einstellungen von IBM Cloud® Code Engine für Begrenzungen und Kontingente.

Wie wirkt sich meine Ressourcenzuweisung auf meine Projektkontingente und die Abrechnung aus?

In der Konsole können Sie Informationen zu Ihrer aktuellen Code Engine-Ressourcenzuordnung von der Seite mit Ihrer Projektübersicht aus anzeigen. Wenn Sie Informationen zum zugewiesenen Speicher und zu den Werten von „ vCPU “ anzeigen möchten, die auf Ihren Konfigurationen für die jeweilige Anwendung oder den jeweiligen Auftrag basieren, sehen Sie sich die Auflistung Ihrer Anwendungen oder Aufträge in Ihrem Projekt an. In der Befehlszeilenschnittstelle können Sie mit dem Befehl project get außerdem Informationen zu Ihrer aktuellen Ressourcenzuordnungsnutzung für das Projekt abrufen.

Bei „ Code Engine “ zahlen Sie nur für die Ressourcen, die Sie tatsächlich nutzen – basierend auf dem konfigurierten Arbeitsspeicher und den von Ihren Workloads verbrauchten „ vCPU “ sowie allen eingehenden „ HTTP “-Anrufen. Wenn Ihre App auf null skaliert wird oder Ihr Job bzw. Ihr Build nicht ausgeführt wird, verbrauchen Sie keine Ressourcen und es fallen daher keine Kosten an. Um alle Anwendungen und Jobs zu hosten, stellt Code Engine die erforderliche Infrastruktur für Sie bereit und verwaltet sie. Diese Infrastruktur wird Ihnen zwar nicht in Rechnung gestellt, trägt jedoch zum Projektkontingent bei. Weitere Informationen zu Quoten finden Sie in den folgenden Tabellen.

Die Verwendung von Kurzzeitspeichern ist jetzt durch den Speicher begrenzt. Der ephemere Speicher in Code Engine kann den Standardwert von 0.4 GB (400 MB) oder den konfigurierten Wert für den Speicher nicht überschreiten. Wenn Sie mehr als den Standardspeicher für die Kurzzeitspeicherung benötigen, müssen Sie den Speicher entsprechend den gültigen Kombinationen von vCPU und Speicher erhöhen.

Weitere Informationen über die Beziehung zwischen ephemerem Speicher und Speicher finden Sie unter Unterstützte Speicher- und CPU-Kombinationen.

Anwendungsstandardwerte und -grenzwerte

In der folgenden Tabelle werden die Grenzwerte für Anwendungen aufgelistet.

Grenzwerte für Anwendungen
Kategorie Standard Maximalwert Sie müssen das Maximum erhöhen?
CPU 1.0 12.0 Wenden Sie sich an den IBM Support.
Flüchtiger Speicher 400 M 48 G
(begrenzt durch den Speicher)		 Wenden Sie sich an den IBM Support.
Max. Skalierung 10 250 Wenden Sie sich an den IBM Support.
Hauptspeicher 4 G 48 G Wenden Sie sich an den IBM Support.
Min. Skalierung 0 250 Wenden Sie sich an den IBM Support.
Nebenläufigkeit 100 1000 Wenden Sie sich an den IBM Support.
Zeitlimit 300 Sekunden 600 Sekunden Wenden Sie sich an den IBM Support.

Weitere Informationen zu unterstützten CPU-und Speicherkombinationen finden Sie unter Unterstützte Speicher-und CPU-Kombinationen.

Code Engine hat Grenzwerte für Apps innerhalb eines Projekts.

  • Pro Projekt sind maximal 40 Apps zulässig.
  • Pro Projekt sind insgesamt maximal 120 Überarbeitungen für alle Apps zulässig.

Code Engine unterstützt keine Überbelegung für Anwendungsressourcen. Wenn Sie also eine Anwendung mithilfe der API oder mit kubectl apply -f <yaml>erstellen, müssen die Werte für Resource.Requests und Resource.Limits für CPU, Memoryund Ephemeral Storage angegeben werden und identisch sein.

Jobstandardwerte und -grenzwerte

In der folgenden Tabelle werden die Grenzwerte für Jobs aufgelistet.

Grenzwerte für Jobs
Kategorie Standard Maximalwert Sie müssen das Maximum erhöhen?
Array-Indizes 0 9999999 Wenden Sie sich an den IBM Support.
Array-Größe 1 1000 Nicht zutreffend
CPU 1.0 12.0 Wenden Sie sich an den IBM Support.
Flüchtiger Speicher 400 M 48 G
(begrenzt durch den Speicher)		 Wenden Sie sich an den IBM Support.
Hauptspeicher 4 G 48 G Wenden Sie sich an den IBM Support.
Retries 3 5 Wenden Sie sich an den IBM Support.
Zeitlimit 7200 Sekunden (2 Stunden) 86400 Sekunden (24 Stunden) Wenden Sie sich an den IBM Support.

Array-Indizes sind durch Kommas getrennte Listen oder durch Bindestriche getrennte Indexbereiche, die die auszuführenden Job-Instanzen angeben; zum Beispiel 1,3,6,9 oder 1-5,7-8,10.

Die Array-Größe gibt die Anzahl der Job-Instanzen an, die parallel ausgeführt werden sollen.

Weitere Informationen zu unterstützten CPU-und Speicherkombinationen finden Sie unter Unterstützte Speicher-und CPU-Kombinationen.

Code Engine ist auf 100 Jobs pro Projekt begrenzt. Nachdem 100 Jobläufe gestartet wurden, sollten Sie ältere Jobläufe unbedingt bereinigen, bevor Sie neue Jobläufe starten.

Grenzwert für Jobgröße

In Code Engine gilt ein maximaler Grenzwert für die Jobgröße und Jobausführungen von 10 KiB. Bei der Erstellung oder Aktualisierung von Jobs und Jobausführungen über die Konsole, die Befehlszeilenschnittstelle (CLI) oder die Anwendungsprogrammierschnittstelle (API) überprüft Code Engine die jeweilige Größe des Jobs oder der Jobausführung. Überschreitet die Operation den Grenzwert, wird eine Fehlernachricht aufgrund der überschrittenen Größenbeschränkung ausgegeben. Wenn diese Fehlermeldung angezeigt wird, versuchen Sie, den Umfang Ihres Auftrags oder Ihrer Auftragsausführung auf eine der folgenden Weisen zu reduzieren.

  • Wenn Sie Befehle und Argumente verwenden: Versuchen Sie, die Verwendung dieser Optionen zu reduzieren, verkürzen Sie sie oder verschieben Sie sie in das Container-Image, das vom Job bzw. von der Jobausführung verwendet wird.

  • Wenn Sie Umgebungsvariablen verwenden: Versuchen Sie, weniger Umgebungsvariablen zu verwenden, oder verkürzen Sie sie. Sie können geheime Schlüssel oder Konfigurationszuordnungen für die Definition von Umgebungsvariablen verwenden und diese mit der Option --env-from-secret bzw. --env-from-configmap der Befehle job create, job update, jobrun submit und jobrun resubmit in den Job importieren.

Weitere Informationen zur Fehlerbehebung bei Jobs finden Sie unter „ Fehlerbehebung – Warum kann ich keinen Job einreichen? “.

Funktionsgrenzen

In der folgenden Tabelle sind die Grenzwerte für die Funktionen aufgeführt.

Funktionsgrenzen
Kategorie Maximum
Länge der Laufzeit 120 Sekunden
Hauptspeicher 48.000 MB
Größe des Anfrage- und des Antwortkörpers 5 MB
Codegröße (inline) 100 KB, einschließlich base64 Overhead
Codegröße (lokale Quelle) 200 MB komprimiert
Codegröße (API) 100 KB, einschließlich base64 Overhead

Grenzwerte für Abonnements des periodischen Zeitgebers (Cron)

In der folgenden Tabelle sind die Grenzwerte für das periodische Timer-Abonnement aufgeführt.

Periodische Timer-Grenzwerte
Kategorie Maximum Sie müssen das Maximum erhöhen?
Größe der Daten 4096 Bytes Wenden Sie sich an den IBM Support.

Code Engine begrenzt die Größe der Daten für Ereignisse des periodischen Zeitgebers (Cron) auf maximal 4096 Byte. Wenn Sie Ereignisse des periodischen Zeitgebers (Cron) erstellen oder aktualisieren, überprüft Code Engine die Größe der Cron-Ereignisdaten. Falls die Ereignisdaten des periodischen Zeitgebers (Cron) den Grenzwert überschreiten, wird ein Fehler aufgrund einer überschrittenen Größenbegrenzung ausgegeben. Wenn Sie diese Fehlermeldung erhalten, versuchen Sie, die Größe der Cron-Ereignisdaten auf weniger als 4096 Bytes zu reduzieren.

Weitere Informationen zur Fehlerbehebung für Subskriptionen finden Sie unter Debugging-Subskriptionen.

Projektgrenzwerte

In der folgenden Tabelle sind die Obergrenzen für Projekte aufgeführt.

Projektgrenzwerte
Kategorie Maximum Sie müssen das Maximum erhöhen?
Projekt pro Region 20 Wenden Sie sich an den IBM Support.

Die maximale Anzahl von Projekten umfasst Projekte, die aktiv sind, und Projekte, die nicht dauerhaft gelöscht werden. Wenn Sie ein Projekt löschen, wird es vorläufig gelöscht und kann innerhalb von 7 Tagen wiederhergestellt werden, bevor es endgültig gelöscht wird. Verwenden Sie die Konsole oder die Befehlszeilenschnittstelle (CLI), um soft gelöschte Projekte anzuzeigen. Weitere Informationen finden Sie im Thema Projekt löschen.

Projektkontingente

In der folgenden Tabelle sind die Kontingente für Projekte aufgeführt.

Beachten Sie, dass die Grenzen innerhalb eines Projekts unabhängig voneinander gelten. Wenn eine Grenze erreicht wird, z. B. die Grenze von 512 GB Arbeitsspeicher, kann sich diese Kontingentgrenze auf die Fähigkeit auswirken, eine Arbeitslast auszuführen, selbst wenn eine andere Grenze noch nicht erreicht ist, z. B. 250 Instanzen von Anwendungen oder Aufträgen.

Projektkontingente
Kategorie Beschreibung
Apps Pro Projekt sind maximal 40 Apps zulässig.
Anwendungsrevisionen Pro Projekt sind insgesamt maximal 120 Überarbeitungen für alle Apps zulässig.
Builds Die Anzahl ist auf 100 Buildkonfigurationen pro Projekt begrenzt.
Buildausführungen Die Anzahl ist auf 100 Buildausführungen pro Projekt begrenzt. Danach müssen alte Buildausführungen entfernt oder bereinigt werden.
Konfigurationszuordnungen Die Anzahl ist auf 100 Konfigurationszuordnungen pro Projekt begrenzt.
CPU Die Gesamtkombination für alle App-Instanzen, laufenden Job-Instanzen und laufenden Build-Instanzen darf 128 vCPU nicht überschreiten.
Bereichszuordnungen (benutzerdefiniert) Sie sind auf 80 benutzerdefinierte Domänenzuordnungen pro Projekt beschränkt.
Flüchtiger Speicher Die Gesamtkombination für alle Anwendungsinstanzen, laufenden Auftragsinstanzen und laufenden Build-Instanzen darf 512 G ephemeren Speicher nicht überschreiten.
Flotten Pro Projekt sind maximal 1000 Flotten zulässig.
Funktionen Pro Projekt sind maximal 20 Funktionen zulässig.
Instanzen (aktiv) Die Anzahl der App-Instanzen, Funktionsinstanzen, laufenden Job-Instanzen und laufenden Build-Instanzen darf 250 nicht überschreiten.
Instanzen (gesamt) Die Anzahl aktiver Instanzen und die Anzahl abgeschlossener Job- und Buildinstanzen darf 2500 nicht überschreiten.
Jobs Die Anzahl ist auf 100 Jobs pro Projekt begrenzt.
Jobausführungen Die Anzahl ist auf 100 Jobausführungen pro Projekt begrenzt. Danach müssen alte Buildausführungen entfernt oder bereinigt werden.
Hauptspeicher Die Gesamtkombination für alle Anwendungsinstanzen, laufenden Auftragsinstanzen und laufenden Build-Instanzen darf 512 G Arbeitsspeicher nicht überschreiten.
Geheime Schlüssel Die Anzahl ist auf 100 geheime Schlüssel pro Projekt begrenzt.
Abonnements (IBM Cloud Object Storage) Die Anzahl ist auf 100 Abonnements (Object Storage) pro Projekt begrenzt.
Subnetzpools Sie sind auf 1000 Subnetz-Pools pro Projekt beschränkt.
Abonnements ( Kafka / IBM® Event Streams for IBM Cloud® ) Pro Projekt sind maximal 100 Abonnements für „ Kafka “ zulässig.
Abonnements (Periodischer Zeitgeber (Cron)) Pro Projekt sind Sie sind auf 100 Abonnements des periodischen Zeitgebers (Cron) beschränkt.

Zum Beispiel sind Sie auf 128 vCPU oder 250 aktive Instanzen einer Anwendung oder eines Auftrags beschränkt. Da jedes Limit unabhängig von anderen Limits gilt, nehmen wir an, Sie wollen eine Anwendung auf 250 Instanzen mit 0.125 VCPU skalieren. Diese Werte ergeben etwa 32 vCPU,, was weniger als das Maximum von 128 vCPU ist. Es ist jedoch nicht möglich, 512 Instanzen mit 0.125 vCPU, zu verwenden, wodurch zwar die Höchstzahl von 128 vCPU, erreicht, aber die Höchstzahl von 250 Instanzen überschritten würde.

Grenzwerte erhöhen

Die Grenzwerte sind festgelegt, können aber erhöht werden, indem Sie den IBM Support kontaktieren und einen Supportfall erstellen.