View a markdown version of this page

Shared Plan Cache verwenden - Amazon Aurora

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ßlichsearch_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 und apg_shared_plan_cache() apg_shared_plan_cache_stat()

  • apg_shared_plan_cache_remove(cache_key)— Entfernt einen Eintrag an der apg_shared_plan_cache() Stelle, an der der Eintrag mit dem übereinstimmt cache_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)