Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Shared Plan Cache verwenden
-Übersicht
Aurora PostgreSQL verwendet ein Prozess-pro-Benutzer-Modell, bei dem jede Client-Verbindung einen dedizierten Backend-Prozess erstellt. Jeder Backend-Prozess unterhält seinen eigenen lokalen Plan-Cache für vorbereitete Anweisungen. Da diese Caches nicht von Prozessen gemeinsam genutzt werden können, erstellen Anwendungen, die viele vorbereitete Anweisungen verwenden, möglicherweise doppelte Caches in verschiedenen Backend-Prozessen, was zu einem erhöhten Speicherverbrauch führt.
Die Aurora PostgreSQL-Versionen 17.6 und höher sowie 16.10 und höher führen die Cache-Funktionalität für gemeinsam genutzte Pläne ein. Wenn Sie diese Funktion aktivieren, können Backend-Prozesse generische Pläne gemeinsam nutzen, wodurch der Speicherverbrauch reduziert und die Leistung verbessert wird, da keine doppelte Plangenerierung erforderlich ist.
Anmerkung
Babelfish for Aurora PostgreSQL unterstützt den Shared-Plan-Cache ab den Versionen 4.10 und 5.6.
Der Shared-Plan-Cache verwendet die folgenden Komponenten als Cache-Schlüssel:
Abfragezeichenfolge (einschließlich Kommentaren)
Planner-related GUC-Parameter (einschließlich
search_path)Benutzer-ID
Datenbank-ID
Instanzneustarts setzen den gemeinsamen Cache zurück.
Parameters
In der folgenden Tabelle werden die Parameter beschrieben, die die Cache-Funktion für gemeinsame Tarife steuern:
| Parameter | Description | Standard | Zulässig |
|---|---|---|---|
apg_shared_plan_cache.enable |
Schaltet den Cache für gemeinsam genutzte Tarife ein oder aus | 0 (AUS) | 0, 1 |
apg_shared_plan_cache.max |
Die maximale Anzahl von Cache-Einträgen | 200—1000 (abhängig von der Instanzgröße) | 100—50000 |
apg_shared_plan_cache.min_size_per_entry |
Die Mindestgröße des Plans, der im gemeinsam genutzten Cache gespeichert werden soll. Kleinere Pläne verwenden den lokalen Cache, um die OLTP-Leistung zu optimieren. | 16 KB | 0—32768 (KB) |
apg_shared_plan_cache.max_size_per_entry |
Die maximale Plangröße für den gemeinsam genutzten Cache. Größere Pläne speichern nur Kosteninformationen. | 256 KB — 4 MB (abhängig von der Instanzgröße) | 0—32768 (KB) |
apg_shared_plan_cache.idle_generic_plan_release_timeout |
Die Zeit, nach der inaktive Sitzungen lokale generische Pläne veröffentlichen. Niedrigere Werte sparen Speicherplatz; höhere Werte können die Leistung verbessern. | 10 Sekunden | 0—2147483647 (ms) |
Anmerkung
Sie können alle Parameter ohne Neustart ändern.
Überwachung von Ansichten und Funktionen
apg_shared_plan_cache()— Zeigt detaillierte Informationen zum Cache-Eintrag an (Treffer, Gültigkeit, Zeitstempel)apg_shared_plan_cache_stat()— Zeigt Statistiken auf Instanzebene an (Räumungen, Invalidierungen)apg_shared_plan_cache_reset()— Entfernt alle Einträge in undapg_shared_plan_cache()apg_shared_plan_cache_stat()apg_shared_plan_cache_remove(cache_key)— Entfernt einen Eintrag an derapg_shared_plan_cache()Stelle, an der der Eintrag mit dem übereinstimmtcache_key
Einschränkungen
Funktioniert nur mit vorbereiteten Anweisungen und speichert keine PL/pgSQL Anweisungen im Cache
Zwischenspeichert keine Abfrage, die temporäre Tabellen oder Katalogtabellen enthält
Zwischenspeichert keine Abfrage, die von RLS (Row-Level Sicherheit) abhängt
Jedes Replikat verwaltet seinen eigenen Cache (keine replikatübergreifende gemeinsame Nutzung)