In Google Cloud werden Kontingente verwendet, um den Umfang einer bestimmten freigegebenen Google Cloud-Ressource einzuschränken. Jedes Kontingent stellt eine bestimmte zählbare Ressource, z. B. API-Aufrufe an einen bestimmten Dienst, die Anzahl der Byte, die an einen bestimmten Dienst gesendet wurden, oder die Anzahl der verwendeten Streamingverbindungen gleichzeitig durch Ihr Projekt.
Viele Dienste haben auch Limits, die nicht mit dem Kontingentsystem in Zusammenhang stehen. Dies sind feste Einschränkungen, wie die maximale Nachrichtengröße oder die Anzahl der Pub/Sub-Ressourcen, die Sie in einem Projekt erstellen können, die nicht gestiegen oder gesunken sein.
Kontingente ansehen und verwalten
Sie können die aktuellen Kontingentlimits eines Projekts und deren Nutzung im Dashboard "IAM & Verwaltung" für Kontingente ansehen. Sie können dieses Dashboard auch für folgende Aufgaben verwenden:
- Kontingentlimits reduzieren
- Höhere Kontingentlimits beantragen
Weitere Informationen zum Monitoring und zu Benachrichtigungen zu Ihrer Kontingentnutzung finden Sie unter Monitoring.
Attribution der Kontingentnutzung
Für den Push-Abonnentendurchsatz wird die Kontingentnutzung anhand des Projekts berechnet, in dem das Push-Abo enthalten ist. Dies ist das Projekt, das im Namen das Abo abzuschließen.
Bei allen anderen Kontingenten wird die Nutzung dem Projekt in Rechnung gestellt, Anmeldedaten, die in der Anfrage angegeben sind. Die Kontingentnutzung wird nicht dem Projekt in Rechnung gestellt, das die angeforderte Ressource enthält.
Beispiel: Wenn ein Dienstkonto in Projekt A eine Veröffentlichungsanfrage an
in einem Thema in Projekt B veröffentlichen, wird das Kontingent Projekt A in Rechnung gestellt.
In einigen Fällen möchten Sie vielleicht, dass die Kontingentnutzung mit einer anderen
Projekt arbeiten. Sie können den Systemparameter X-Goog-User-Project
für Folgendes verwenden:
Projekt für die Kontingentattribution ändern. Weitere Informationen zu X-Goog-User-Project
Siehe Systemparameter.
Sie können die gcloud CLI verwenden, um das Projekt für die Kontingentattribution festzulegen
für eine bestimmte Anfrage. Die gcloud CLI sendet
X-Goog-User-Project
-Anfrageheader
Sie müssen die Rolle roles/serviceusage.serviceUsageConsumer
haben
oder eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.services.use
für das Projekt
die Sie für die Kontingentzuordnung verwenden.
Das folgende Beispiel zeigt, wie Sie eine Liste der Abos im Projekt abrufen. RESOURCE_PROJECT während der Belastung durch den Administrator Vorgänge für das Projekt QUOTA_PROJECT. Ausführen den folgenden Befehl in Ihrem Google Cloud CLI-Terminal ein:
gcloud pubsub subscriptions list --project=
RESOURCE_PROJECT --billing-project=
QUOTA_PROJECT
Ersetzen Sie QUOTA_PROJECT
durch die ID des Google Cloud-Projekts, für das Sie das Kontingent berechnen möchten.
In Pub/Sub ist das abgerechnete Projekt immer das Projekt, enthält die Ressource. Sie können das Projekt nur für die Kontingentzuordnung ändern.
Pub/Sub Kontingente
Die in der folgenden Tabelle aufgelisteten Kontingente können pro Projekt im Dashboard „APIs & Dienste“ für Kontingente aufgerufen und bearbeitet werden.
Regionale Kontingente sind in drei Typen unterteilt:
- Große Regionen:
europe-west1
,europe-west4
,us-central1
,us-east1
,us-east4
,us-west1
,us-west2
- Mittlere Regionen:
asia-east1
,asia-northeast1
,asia-southeast1
,europe-west2
,europe-west3
- Kleine Regionen: alle anderen Regionen
Kontingente für genau einmalige Zustellung sind regionsspezifisch. Sehen Sie sich die Details für jede Region in der folgenden Tabelle an.
Kontingent | Standardkontingentlimit | Beschreibung |
---|---|---|
Publisher-Durchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der veröffentlichten
In einer Veröffentlichungsanfrage können mehrere Nachrichten enthalten sein. Für diese Nachrichten wird kein zusätzliches Kontingent berechnet. |
Pull-Abonnentendurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der zurückgegebenen
|
Bestätigungsdurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der
|
Push-Abos – Durchsatz pro Region |
|
Bei Push-Zustellungsanfragen an den Push-Endpunkt richtet sich die Kontingentnutzung nach der Größe der an den Push-Endpunkt gesendeten |
BigQuery-Abos: Durchsatz pro Region |
|
Bei Anfragen an BigQuery
Die Kontingentnutzung basiert auf der Größe der |
Cloud Storage-Abos Durchsatz pro Region |
|
Bei Anfragen an Cloud Storage
Die Kontingentnutzung basiert auf der Größe der gesendeten |
StreamingPull-Abonnentendurchsatz pro Region |
|
Die Kontingentnutzung beruht auf der Größe der
Für Clientbibliotheken werden nach Möglichkeit Vorgänge vom Typ StreamingPull verwendet. |
Anzahl der offenen StreamingPull-Verbindungen pro Region |
|
Die Anzahl der offenen StreamingPull-Verbindungen zu einem beliebigen Zeitpunkt. Siehe StreamingPull. |
Verwaltungsvorgänge | 6.000 pro Minute (100 Vorgänge pro Sekunde) |
Für jeden Verwaltungsvorgang wie etwa GetTopicRequest wird diesem Kontingent eine Einheit angerechnet.
|
Anzahl der Nachrichten, die über Abos mit aktivierter Auslieferung genau einmal pro Region verbraucht wurden |
|
Die Kontingentnutzung
basiert auf der Anzahl der
Vom Abonnenten verbrauchte
|
Anzahl der bestätigten Nachrichten oder deren Frist verlängert wurde wenn Abos mit aktivierter genau einmaliger Zustellung pro Region verwendet werden |
|
Die Kontingentnutzung basiert auf der Anzahl der Bestätigungs-IDs in
|
Durchsatzkontingenteinheiten
Die Nutzung von Durchsatzkontingenten wird in Einheiten von 1 KB gemessen. 1 KB entspricht 1.000 Byte. Beispiel: In einer PublishRequest
mit 105 Nachrichten mit jeweils 50 Byte beträgt die Nutzerdatengröße 105 * 50 bytes = 5250 bytes
. Die Kontingentnutzung beläuft sich also auf max(1kB, ceil(5250 bytes/1000)) = 6kB
.
Ressourcenlimits
Ressource | Limits |
---|---|
Projekt |
10.000 Themen 10.000 angehängte oder getrennte Abos 5.000 Snapshots 10.000 Schemas |
Thema |
10.000 angehängte Abos 5.000 angehängte Snapshots Ist die Aufbewahrung von Themennachrichten konfiguriert, können Nachrichten, die zu einem Thema veröffentlicht wurden, bis zu 31 Tage ab dem Zeitpunkt der Veröffentlichung im nichtflüchtigen Speicher gespeichert werden. |
Abo |
Bewahrt nicht quittierte Nachrichten ab der Veröffentlichung standardmäßig sieben Tage lang im nichtflüchtigen Speicher auf. Es gibt keine Begrenzung für die
Anzahl der aufbewahrten Nachrichten. Wenn Abonnenten ein Abo nicht nutzen, läuft es ab. Die standardmäßige Ablaufzeit beträgt 31 Tage. |
Schema | Schemagröße (Feld definition ): 300 KBÜberarbeitungen pro Schema: 20 |
Veröffentlichungsanfrage | 10 MB (Gesamtgröße) 1.000 Nachrichten |
Meldung | Nachrichtengröße (Feld data ): 10 MBAttribute pro Nachricht: 100 Attributschlüsselgröße: 256 Byte Attributwertgröße: 1.024 Byte |
StreamingPull-Streams | 10 MB/s pro offenem Stream |
Unäre Pull-Antwort |
Maximale Anzahl von Nachrichten in einer Pull-Antwort: 1.000 Maximale Größe einer Pull-Antwort: 10 MB |
Pull-/StreamingPull-Nachrichten | Der Dienst kann Limits festlegen, die die Gesamtzahl der pro Verbindung ausstehenden StreamingPull-Nachrichten regeln. Wenn Sie ein solches Limit erreichen, sollten Sie die Rate, mit der Sie Nachrichten bestätigen, und die Anzahl der verwendeten Verbindungen erhöhen. |
Bestätigen und ModifyAckDeadline-Anfragen |
512 KB (Gesamtgröße) |
Schlüssel anordnen | Wenn Nachrichten die Schlüsselreihenfolge liegt der maximale Publisher-Durchsatz bei 1 Mbit/s pro Bestellschlüssel. |
Dienstkonto für höhere Kontingente verwenden
Wenn Sie das gcloud-Tool der Google Cloud CLI mit einem normalen Nutzerkonto (d. h. einem nicht Dienstkonto sind), sind Pub/Sub-Vorgänge auf eine bestimmte Rate für manuelle Vorgänge geeignet. Raten, die diese Grenze überschreiten, führen zu RESOURCE_EXHAUSTED-Fehler. Dies können Sie durch die Verwendung von Anmeldedaten für ein Dienstkonto verhindern. Wenn Sie zur Automatisierung die Anmeldedaten der gcloud CLI verwenden möchten, aktivieren Sie ein Dienstkonto für Ihre Pub/Sub-Vorgänge.
Standortendpunkte zum Weiterleiten von Anfragen verwenden
Wenn Sie in bestimmten Regionen zusätzliche Kontingente haben, können Sie Anfragen mithilfe standortbezogener Pub/Sub-Endpunkte an diese Regionen weiterleiten. Wenn Sie Nachrichten in einem globalen Endpunkt veröffentlichen, leitet der Pub/Sub-Dienst den Traffic möglicherweise an eine Region weiter, die nicht über ausreichende Kontingente verfügt.
Kontingentabweichungen
Kontingentabweichungen können auftreten, wenn veröffentlichte oder empfangene Nachrichten kleiner als 1.000 Byte sind. Beispiel:
Wenn Sie zehn Nachrichten mit je 500 Byte in separaten Anfragen veröffentlichen, beträgt Ihre Kontingentnutzung als Publisher 10.000 Byte. Das liegt daran, dass Nachrichten unter 1.000 Byte automatisch auf 1.000 Byte aufgerundet werden.
Wenn Sie die zehn Nachrichten innerhalb einer einzelnen Pull-Antwort empfangen, beträgt Ihre Kontingentnutzung als Abonnent möglicherweise nur 5 KB. Dies liegt daran, dass für die Bestimmung des Gesamtkontingents die Nachrichten in ihrer tatsächlichen Größe zusammengefasst werden.
Auch das Gegenteil kann der Fall sein. Die Kontingentnutzung als Abonnent kann über der Kontingentnutzung als Publisher liegen, wenn Sie mehrere Nachrichten in einer einzelnen Veröffentlichungsanfrage veröffentlichen oder die Nachrichten in separaten Pull-Anfragen empfangen.