AlloyDB for PostgreSQL verwendet Kontingente und Systemlimits, um eine faire Ressourcenzuweisung zu gewährleisten, Dienstüberlastungen zu vermeiden und Sie bei der Verwaltung der Ressourcennutzung zu unterstützen.
Kontingente und Systemlimits sind ähnlich, unterscheiden sich aber in folgenden Punkten:
- 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.
Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Ihre Nutzung von Google Cloud steigt, können sich Ihre Kontingente erhöhen.
Weitere Informationen zu Kontingenten finden Sie in der Dokumentation zu Cloud-Kontingenten.
Informationen zu den von AlloyDB festgelegten Kontingenten 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
Um Ihre Kontingente aufzurufen, 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 aktuell gültigen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt finden Sie in der Tabelle in der Liste Filter.
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 Kontingenttabelle auf Filtern.
Wählen Sie in der Liste Attribute die Option Dienst und dann in der Liste 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 Attribute die Option Dienst und dann in der Liste Werte die Option AlloyDB API aus.
Wenn Sie die AlloyDB API nicht sehen, wurde 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 Ihre Ratenbegrenzungen angerechnet. Wenn Sie mithilfe von Dienstkonten auf die API zugreifen, werden diese Anfragen auch auf Ihr Ratenlimit angerechnet.
Die Ratenkontingente werden erzwungen und automatisch in 60-Sekunden-Intervallen (1 Minute) neu aufgefüllt. Wenn Ihr Projekt also innerhalb von 60 Sekunden das Maximum eines Ratenkontingents erreicht, müssen Sie warten, bis dieses Kontingent wieder aufgefüllt ist, bevor Sie weitere Anfragen in dieser Gruppe 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 gibt AlloyDB ein separates Kontingent an. Wenn beispielsweise 100 Nutzer in einer Minute auf die Mutate APIs für ein bestimmtes Projekt und eine bestimmte Region zugreifen, erhält jeder Nutzer ein Standardkontingent im Bereich von 180–250 Anfragen pro Minute für jede Kombination aus Projekt und Region.
Der Standardkontingentbereich für jede Gruppe ist folgender:
| Gruppenname | Beschreibung | Standardkontingentbereich in Abfragen pro Minute | API-Methoden |
|---|---|---|---|
| Connect APIs | Neue Verbindungen herstellen | 180-2000 |
|
| APIs abrufen | Einzelne Ressource lesen. | 180-1000 |
|
| Get-Vorgangs-API | Letzten Status eines Vorgangs mit langer Ausführungszeit abrufen. | 950-2000 |
|
| APIs auflisten | Eine Gruppe von Ressourcen desselben Typs lesen. | 180-1000 |
|
| Listenvorgangs-API | 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 Zuteilungskontingente 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 einem 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.
Ressourcenkontingente werden für die Anzahl der verwendeten Cluster und vCPUs festgelegt, 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 eine Anfrage zum Erstellen oder Wiederherstellen eines Clusters über die Google Cloud Console, die gcloud CLI oder die AlloyDB API stellen und dies zu einer Kontingentverletzung führt, schlägt die Anfrage mit einer Fehlermeldung wie 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 einer Kontingentverletzung führt, schlägt die Anfrage mit einer Fehlermeldung wie 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 Schreibanfrage an die Datenbank stellen, z. B. eine INSERT-Anweisung, die zu einer Kontingentverletzung führt, schlägt die Anfrage mit der folgenden Fehlermeldung fehl:
AlloyDB instance exceeds available storage quota.
Ressourcenverfügbarkeit
Ressourcenkontingente sind keine Garantie dafür, dass physische Hardwareressourcen jederzeit in einer Region oder Zone verfügbar sind. Wenn eine bestimmte Maschinenreihe oder -form in Ihrer Zielregion vorübergehend nicht verfügbar ist, können Vorgänge zum Erstellen, Starten oder Skalieren eines Clusters oder einer Instanz fehlschlagen, auch wenn Ihr Projekt noch über Kontingent verfügt. Da AlloyDB die zugrunde liegenden Compute Engine-VMs in von Google verwalteten Mandantenprojekten verwaltet, gelten Compute Engine-Reservierungen nicht für AlloyDB-Ressourcen.
Um vorübergehende Ressourcenbeschränkungen zu umgehen, können Sie den Vorgang nach einer Verzögerung wiederholen, eine andere Maschinenserie oder vCPU-Größe auswählen oder in einer anderen Region bereitstellen. Ausführliche Informationen finden Sie unter Best Practices für die Kapazitätsplanung und Ressourcenverfügbarkeit und Best Practices für die Skalierung und Ressourcenverfügbarkeit.
Limits
| Element | Limit |
|---|---|
| Lesepoolknoten pro Cluster (über alle Lesepoolinstanzen hinweg) | 20 |
| Maximale Anzahl gleichzeitiger Verbindungen pro Instanz | Das Standardlimit variiert je nach Instanzgröße und kann bis zum maximalen Limit angepasst werden, das von dieser 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 Wert für max_connections basierend auf der Instanzgröße aus:
| VCPU | Arbeitsspeicher (GB) | Standardwert für max_connections |
Empfohlener max_connections-Maximalwert |
|---|---|---|---|
| 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 Folgendes, 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 diesen überschreiten. - Bevor Sie eine vorhandene Instanz verkleinern, aktualisieren Sie den Wert des Flags
max_connectionsentsprechend. Andernfalls können Probleme auftreten. - 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 höher als die Empfehlungen festlegen (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 reduzieren würde.
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 |