In diesem Dokument sind die Kontingente und Systemlimits für AlloyDB for PostgreSQL aufgeführt.
- Kontingente haben Standardwerte, aber Sie können in der Regel Anpassungen anfordern.
- Systemlimits sind feste Werte, die nicht geändert werden können.
Kontingente
Google Cloud nutzt Kontingente, um für Fairness zu sorgen und Spitzen bei der Ressourcennutzung und ‑verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud Ressource Ihr Google Cloud Projekt nutzen kann. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt nebenläufig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud Nutzer schützen. Sie helfen Ihnen auch bei der Verwaltung Ihrer eigenen Google Cloud Ressourcen.
Das Cloud-Kontingentsystem tut Folgendes:
- Es überwacht Ihren Verbrauch von Google Cloud Produkten und Diensten.
- Es schränkt Ihren Verbrauch dieser Ressourcen ein.
- Es bietet eine Möglichkeit, Änderungen am Kontingentwert zu beantragen und Kontingentanpassungen zu automatisieren.
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie auszuführen versuchen, schlägt dann fehl.
Kontingente gelten in der Regel auf Google Cloud Projektebene. Die Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf das verfügbare Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Weitere Informationen finden Sie unter Cloud-Kontingente – Übersicht.
Google Cloud bietet auch kostenlose Testkontingente, die einen eingeschränkten Zugriff für Projekte ermöglichen, damit Sie Google Cloud kostenlos testen können.
Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Ihre Google Cloud Nutzung zunimmt, können sich Ihre Kontingente erhöhen.
Weitere Informationen zu Kontingenten finden Sie in der Dokumentation zu Cloud-Kontingenten.
Informationen zu Kontingenten, die von AlloyDB auferlegt werden, finden Sie unter Ratenkontingente und Ressourcenkontingente.
Für AlloyDB-Ressourcen gelten außerdem Limits. Im Gegensatz zu Kontingenten können Systemlimits nicht geändert werden.
Berechtigungen zum Prüfen und Bearbeiten von Kontingenten
Zum Aufrufen Ihrer Kontingente benötigen Sie die Berechtigung serviceusage.quotas.get.
Um Ihre Kontingente zu ändern, ist die Berechtigung serviceusage.quotas.update erforderlich.
Diese Berechtigungen sind standardmäßig in den einfachen IAM-Rollen "Inhaber" und "Bearbeiter" sowie in der vordefinierten Rolle "Kontingentadministrator" enthalten.
Kontingente prüfen
Standardmäßig werden in der Kontingenttabelle in der Google Cloud Console Kontingente für alle Dienste aufgeführt. Die aktuellen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt können Sie in der Tabelle über die Liste Filter aufrufen.
So prüfen Sie die aktuellen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt:
Rufen Sie in der Google Cloud Console die Seite Kontingente auf.
Klicken Sie in der Tabelle „Kontingente“ auf Filtern.
Wählen Sie in der Liste Properties (Eigenschaften) die Option Service (Dienst) und dann in der Liste Values (Werte) die Option AlloyDB API aus.
Kontingente erhöhen
Bei einer intensiveren Nutzung von Google Cloud können Ihre Kontingente entsprechend erhöht werden. Wenn Sie eine deutlich höhere Nutzung erwarten, sollten Sie schon einige Tage vorher entsprechend höhere Kontingente anfordern.
- Klicken Sie auf der Seite Kontingente auf Filter.
Wählen Sie in der Liste Properties (Eigenschaften) die Option Service (Dienst) und dann in der Liste Values (Werte) die Option AlloyDB API aus.
Wenn Sie die AlloyDB API nicht sehen, ist die AlloyDB Admin API nicht aktiviert.
Wählen Sie die Kontingente aus, die Sie ändern möchten.
Klicken Sie auf Kontingente bearbeiten.
Geben Sie Ihren Namen, Ihre E‑Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
Geben Sie die Kontingentanfrage ein und klicken Sie auf Anfrage senden.
Ratenkontingente
AlloyDB unterstützt Ratenkontingente, die auch als Ratenbegrenzungen oder API-Kontingente bezeichnet werden. Ratenkontingente definieren die Anzahl der Anfragen, die Sie an die AlloyDB API senden können.
Jedes Ratenkontingent entspricht allen Anfragen für eine Gruppe von einer oder mehreren AlloyDB API-Methoden. Ratenkontingente werden nach einem für den Dienst spezifischen Zeitintervall zurückgesetzt, z. B. die Anzahl der API-Anfragen pro Tag.
Wenn Sie die Google Cloud CLI oder die Google Cloud Console verwenden, stellen Sie Anfragen an die API. Diese Anfragen werden auf die Ratenbegrenzungen angerechnet. Dasselbe gilt für Zugriffe auf die API über Dienstkonten.
Die Ratenkontingente werden in 60-Sekunden-Intervallen (1 Minute) erzwungen und automatisch neu aufgefüllt. Wenn Ihr Projekt also innerhalb von 60 Sekunden das Maximum eines Ratenkontingents erreicht, müssen Sie warten, bis dieses Kontingent aufgebraucht ist, bevor Sie in dieser Gruppe weitere Anfragen stellen. Wenn Ihr Projekt eine Ratenbegrenzung überschreitet, erhalten Sie den HTTP-Statuscode 429 mit dem Grund rateLimitExceeded.
Die AlloyDB-APIs sind je nach Vorgangstyp in sechs Gruppen unterteilt. Die Ratenkontingente gelten pro Minute, API-Gruppe, Projekt, Region und Nutzer. Für jede eindeutige Kombination dieser Attribute gilt in AlloyDB ein separates Kontingent. Wenn beispielsweise 100 Nutzer in einer Minute für ein bestimmtes Projekt und eine bestimmte Region auf die Mutate APIs zugreifen, erhält jeder Nutzer ein Standardkontingent von 180 bis 250 Anfragen pro Minute für jede Kombination aus Projekt und Region.
Der Standardkontingentbereich für jede Gruppe ist:
| Gruppenname | Beschreibung | Standardkontingentbereich in Abfragen pro Minute | API-Methoden |
|---|---|---|---|
| Connect APIs | Neue Verbindungen herstellen | 180-2000 |
|
| APIs abrufen | Einzelne Ressource lesen | 180-1000 |
|
| API für Vorgang abrufen | Ruft den letzten Status eines Vorgangs mit langer Ausführungszeit ab. | 950-2000 |
|
| APIs auflisten | Eine Gruppe von Ressourcen desselben Typs lesen. | 180-1000 |
|
| API zum Auflisten von Vorgängen | Listet Vorgänge auf, die zu einem bestimmten Filter in der Anfrage passen. | 2200-3000 |
|
| Mutate-APIs | Ressourcenstatus ändern. | 180-250 |
|
Ressourcenkontingente
AlloyDB unterstützt Ressourcenkontingente, die auch als Zuweisungskontingente bezeichnet werden. Mit Ressourcenkontingenten wird festgelegt, wie viele Ressourcen eines Typs Sie maximal erstellen können, wenn diese Ressourcen verfügbar sind. Ressourcenkontingente schränken die Nutzung von Ressourcen ein, die keine Nutzungsrate haben, z. B. die Anzahl der VM-Instanzen, die zu einem bestimmten Zeitpunkt von Ihrem Projekt verwendet werden.
Ressourcenkontingente werden nicht nach Ablauf einer bestimmten Zeit zurückgesetzt. Stattdessen müssen Sie Maßnahmen ergreifen, um die nicht verwendeten Ressourcen freizugeben, z. B. einen nicht benötigten Cluster löschen.
Für die Anzahl der verwendeten Cluster und vCPUs gelten Ressourcenkontingente, wie in den folgenden Abschnitten beschrieben.
Ressourcenkontingente für Cluster
Dieses Kontingent gilt für die Anzahl der Cluster pro Projekt und Region. Der Standardwert für dieses Kontingent liegt je nach Nutzungsverlauf des Projekts zwischen 3 und 10 Clustern pro Projekt und Region. Der maximal unterstützte Wert für dieses Kontingent beträgt 20 Cluster pro Projekt und Region.
Wenn Sie über die Google Cloud -Konsole, die gcloud CLI oder die AlloyDB API eine Anfrage zum Erstellen oder Wiederherstellen eines Clusters stellen und dies zu einem Kontingentverstoß führt, schlägt die Anfrage mit einer Fehlermeldung ähnlich der folgenden fehl:
Quota limit 'ClustersUsedPerProjectPerRegion' has been exceeded. Limit: 5 in region us-central1.
Ressourcenkontingente für vCPUs
Dieses Kontingent gilt für die Anzahl der vCPUs pro Projekt und Region. Jede Instanz verbraucht einen Teil dieses Kontingents, je nachdem, wie viele VMs sie verwendet. Jede primäre Instanz verwendet zwei VMs. Jede Lesepoolinstanz verwendet eine VM für jeden Knoten, den sie enthält. Die Anzahl der von jeder VM verwendeten vCPUs wird von Ihnen beim Erstellen oder Aktualisieren der Instanz angegeben.
Der Standardwert des Kontingents für alle Kundenprojekte beträgt 10.000 vCPUs.
Wenn Sie eine Anfrage zum Erstellen oder Aktualisieren einer Instanz über die Google Cloud Console, die gcloud CLI oder die AlloyDB API stellen und dies zu einem Kontingentverstoß führt, schlägt die Anfrage mit einer Fehlermeldung ähnlich der folgenden fehl:
Quota limit 'VCPUsUsedPerProjectPerRegion' has been exceeded. Limit: 128 in region us-central1.
Ressourcenkontingente für Speicher
Dieses Kontingent gilt für die Datenmenge, die in jedem Cluster gespeichert werden kann. Der Standardwert für dieses Kontingent beträgt 16 TiB pro Cluster. Der maximal unterstützte Wert beträgt 128 TiB pro Cluster.
Wenn Sie eine Datenbank-Schreibanfrage stellen, z. B. eine INSERT-Anweisung, die zu einem Kontingentverstoß führt, schlägt die Anfrage mit der folgenden Fehlermeldung fehl:
AlloyDB instance exceeds available storage quota.
Ressourcenverfügbarkeit
Ressourcenkontingente garantieren nicht, dass Ressourcen jederzeit verfügbar sind. Wenn eine Ressource für Ihre Region physisch nicht verfügbar ist, können Sie keine neuen Ressourcen dieses Typs erstellen, selbst wenn in Ihrem Projekt noch ausreichendes Kontingent vorhanden ist.
Limits
Fordern Sie einen Supportfall an, um eine Erhöhung des Limits anzufordern.
| Element | Limit |
|---|---|
| Lesepoolknoten pro Cluster (für alle Lesepoolinstanzen) | 20 |
| Maximale Anzahl gleichzeitiger Verbindungen pro Instanz | Das Standardlimit variiert je nach Instanzgröße. Es kann bis zum maximalen Limit angepasst werden, das von der jeweiligen Größe unterstützt wird. |
Maximale Anzahl gleichzeitiger Verbindungen
Standardmäßig legt AlloyDB die maximale Anzahl gleichzeitiger Verbindungen für eine Instanz basierend auf ihrer Größe fest. Wenn Sie dieses Limit ändern möchten, legen Sie das Flag max_connections fest.
Wählen Sie anhand der folgenden Tabelle den max_connections-Wert basierend auf der Größe Ihrer Instanz aus:
| VCPU | Arbeitsspeicher (GB) | Standardwert für max_connections |
Empfohlener Maximalwert für max_connections |
|---|---|---|---|
| 1 | 8 | 100 |
200 |
| 2 | 16 | 100 |
570 |
| 4 | 32 | 200 |
980 |
| 8 | 64 | 400 |
2300 |
| 14 | 112 | 700 |
4000 |
| 16 | 128 | 800 |
4600 |
| 22 | 176 | 1000 |
6300 |
| 32 | 256 | 1000 |
9175 |
| 44 | 352 | 1000 |
12600 |
| 48 | 384 | 1000 |
13760 |
| 64 | 512 | 1000 |
18350 |
| 72 | 576 | 1000 |
20640 |
| 88 | 704 | 1000 |
25230 |
| 96 | 768 | 1000 |
27525 |
| 128 | 864 | 1000 |
30960 |
| 144 | 1152 | 1000 |
41290 |
Beachten Sie die folgenden Hinweise, bevor Sie den Wert festlegen:
- Wenn Sie das Flag
max_connectionsfür eine Lesepoolinstanz festlegen, muss der neue Wert demmax_connections-Wert der primären Instanz des Clusters entsprechen oder ihn überschreiten. - Bevor Sie die Größe einer vorhandenen Instanz verringern, aktualisieren Sie den Wert des Flags
max_connectionsentsprechend. Andernfalls kann es zu Problemen kommen. - Wir empfehlen, maximal vier gleichzeitige Abfragen pro Instanz-vCPU auszuführen.
- Für Arbeitslasten mit kurzfristigen Verbindungen sollten Sie einen Verbindungspooler wie pgbouncer oder pgpool-II verwenden.
- Wir empfehlen, einen anwendungsseitigen Verbindungspooler wie HikariCP oder c3p0 hinzuzufügen.
Wenn Sie den Wert auf einen Wert festlegen, der höher als die Empfehlungen ist (bis zu 240.000), sollten Sie den zusätzlichen Arbeitsspeicherverbrauch für jede aktive Verbindung berücksichtigen, der den Arbeitsspeicher für den gemeinsamen Zwischenspeicher verringert.
Dieser Arbeitsspeicherverbrauch kann berechnet werden, indem die Anzahl der gleichzeitigen Abfragen mit dem für das Flag
work_memfestgelegten Wert multipliziert wird. Der Standardwert für dieses Flag ist4MBoder die Anzahl der vCPUs in der Instanz, je nachdem, welcher Wert höher ist.
Limits für gespeicherte Abfragen
| Wert | Limit |
|---|---|
| Maximale Anzahl gespeicherter Abfragen pro Projekt (einschließlich gespeicherter Abfragen für andere Google Cloud -Produkte) | 10.000 |
| Maximale Größe für jede Anfrage | 1 MiB |