In diesem Dokument sind die für AlloyDB for PostgreSQL geltenden Kontingente und Systemlimits 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 dem Cloud-Kontingente – Übersicht.
Google Cloud bietet auch kostenlose Probekontingente, mit denen Sie kostenlos testen können. Google Cloud
Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Ihre Google Cloud Nutzung steigt, können Ihre Kontingente erhöht werden.
Weitere Informationen zu Kontingenten finden Sie in der Dokumentation zu Cloud-Kontingenten.
Informationen zu spezifischen Kontingenten, die von AlloyDB auferlegt werden, finden Sie unter Ratenkontingente und Ressourcenkontingente.
Es gibt auch Limits für AlloyDB-Ressourcen. Im Gegensatz zu Kontingenten können Systemlimits nicht geändert werden.
Berechtigungen zum Prüfen und Bearbeiten von Kontingenten
Sie benötigen die
serviceusage.quotas.get
Berechtigung, um Ihre Kontingente aufzurufen.
Um Ihre Kontingente zu ändern, ist die
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. Sie können die aktuellen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt mit der Liste Filter in der Tabelle prüfen.
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 Filter.
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 erweitert 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 AlloyDB API nicht angezeigt wird, 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 Ihre 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 und diese Anfragen werden auf Ihre Ratenbegrenzungen angerechnet. Wenn Sie mithilfe von Dienstkonten auf die API zugreifen, werden diese Anfragen auch auf Ihre Ratenbegrenzung 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 das Kontingent wieder aufgefüllt ist, bevor Sie weitere Anfragen in dieser Gruppe stellen können. 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 werden pro Minute, pro API-Gruppe, pro Projekt, pro Region und pro Nutzer auferlegt. Für jede eindeutige Kombination dieser Attribute legt AlloyDB ein separates Kontingent fest. Wenn beispielsweise 100 Nutzer innerhalb einer Minute für ein bestimmtes Projekt und eine bestimmte Region auf die Mutate APIs zugreifen, erhält jeder Nutzer ein Standardkontingent im Bereich von 180 bis 250 Anfragen pro Minute für jede Kombination aus Projekt und Region.
Der Standardkontingentbereich für jede Gruppe ist wie folgt:
| Gruppenname | Beschreibung | Standardkontingentbereich in Abfragen pro Minute | API-Methoden |
|---|---|---|---|
| Connect APIs | Neue Verbindungen herstellen | 180–2000 |
|
| Get APIs | Eine einzelne Ressource lesen | 180–1000 |
|
| Get operation API | Neuesten Status eines Vorgangs mit langer Ausführungszeit abrufen | 950–2000 |
|
| List APIs | Eine Gruppe von Ressourcen desselben Typs lesen | 180–1000 |
|
| List operations API | Vorgänge auflisten, die einem bestimmten Filter in der Anfrage entsprechen | 2200–3000 |
|
| Mutate APIs | Ressourcenstatus ändern | 180–250 |
|
Ressourcenkontingente
AlloyDB unterstützt Ressourcenkontingente, die auch als Zuteilungskontingente bezeichnet werden. Ressourcenkontingente legen fest, wie viele Ressourcen eines Typs Sie maximal erstellen können, wenn diese Ressourcen verfügbar sind. Ressourcenkontingente begrenzen die Nutzung von Ressourcen, 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.
Ressourcenkontingente werden für die Anzahl der verwendeten Cluster und vCPUs auferlegt, 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 Nutzungshistorie 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 Console, die gcloud CLI, die AlloyDB API eine Anfrage zum Erstellen oder Wiederherstellen eines Clusters stellen und dies zu einer Kontingentverletzung 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 über die Google Cloud Console, die gcloud CLI, oder die AlloyDB API eine Anfrage zum Erstellen oder Aktualisieren einer Instanz stellen und dies zu einer Kontingentverletzung 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 Datenbankschreibanfrage 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 garantieren nicht, dass Ressourcen jederzeit verfügbar sind. Wenn eine Ressource für Ihre Region nicht physisch verfügbar ist, können Sie keine neuen Ressourcen dieses Typs erstellen, auch wenn Sie noch Kontingent in Ihrem Projekt haben.
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 | Standardmäßig 1.000, anpassbar auf bis zu 240.000 |
Maximale Anzahl gleichzeitiger Verbindungen
AlloyDB begrenzt die maximale Anzahl gleichzeitiger Verbindungen einer Instanz auf 1.000,es sei denn, Sie legen das Flag max_connections auf einen höheren Wert fest.
Verwenden Sie die folgende Tabelle als Richtlinie, um den Wert für die maximale Anzahl von Verbindungen basierend auf der Instanzgröße zu bestimmen:
| VCPU | Arbeitsspeicher | Empfohlener Wert für max_connections |
|---|---|---|
| 1 | 8 | 500 |
| 2 | 16 | 1000 |
| 4 | 32 | 2000 |
| 8 | 64 | 4000 |
| 16 | 128 | 5000 |
| 32 | 256 | 5000 |
| 48 | 384 | 5000 |
| 64 | 512 | 5000 |
| 72 | 576 | 5000 |
| 96 | 768 | 5000 |
| 128 | 864 | 5000 |
Beachten Sie vor dem Festlegen des Werts Folgendes:
- Wenn Sie das Flag
max_connectionsfür eine Lesepoolinstanz festlegen, muss der neue Wert mit dem Wert vonmax_connectionsder primären Instanz des Clusters übereinstimmen oder diesen übersteigen. - Wir empfehlen, maximal vier gleichzeitige Abfragen pro Instanz-vCPU auszuführen.
- Für Arbeitslasten mit kurzzeitigen 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 verringern würde.
Dieser Arbeitsspeicherverbrauch kann berechnet werden, indem Sie die Anzahl der gleichzeitigen Abfragen mit dem für das Flag
work_memfestgelegten Wert multiplizieren. 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 |