Gemeinsamer Plan-Cache verwenden - Amazon Aurora
-ÜbersichtParametersAnsichten und Funktionen überwachenEinschränkungen

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.

Gemeinsamer Plan-Cache verwenden

-Übersicht

Aurora PostgreSQL verwendet ein process-per-user Modell, bei dem jede Client-Verbindung einen dedizierten Backend-Prozess erzeugt. Jeder Backend-Prozess verwaltet seinen eigenen lokalen Plan-Cache für vorbereitete Anweisungen. Da diese Caches nicht von Prozessen gemeinsam genutzt werden können, können Anwendungen, die viele vorbereitete Anweisungen verwenden, doppelte Caches für verschiedene Backend-Prozesse erstellen, was zu einer erhöhten Speicherauslastung 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 gemeinsame Pläne ein. Wenn Sie diese Funktion aktivieren, können Back-End-Prozesse generische Pläne gemeinsam nutzen, wodurch der Speicherverbrauch reduziert und die Leistung verbessert wird, da keine doppelten Pläne generiert werden.

Der Cache für gemeinsam genutzte Pläne verwendet die folgenden Komponenten als Cache-Schlüssel:

  • Abfragezeichenfolge (einschließlich Kommentare)

  • GUC-Parameter im Zusammenhang mit dem Planer (einschließlich) search_path

  • Benutzer-ID

  • Datenbank-ID

Neustarts der Instanz setzen den gemeinsam genutzten Cache zurück.

Parameters

In der folgenden Tabelle werden die Parameter beschrieben, die die Cache-Funktion für gemeinsam genutzte Pläne steuern:

Parameter Description Standard Zulässig
apg_shared_plan_cache.enable Schaltet den Cache für gemeinsam genutzte Pläne 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 Leerlaufsitzungen 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 ändern, ohne einen Neustart durchführen zu müssen.

Ansichten und Funktionen überwachen

  • apg_shared_plan_cache()— Zeigt detaillierte Informationen zu Cache-Einträgen (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, von apg_shared_plan_cache() dem 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 Security) abhängt

  • Jedes Replikat verwaltet seinen eigenen Cache (keine replikatübergreifende gemeinsame Nutzung)