Snowflake Postgres-Einblicke¶

Cache-Treffer¶

Postgres versucht im Allgemeinen, die Daten, auf die Sie am häufigsten zugreifen, in seinem Cache für gemeinsame Puffer beizubehalten. Das Cache-Trefferverhältnis misst, wie viele Inhaltsanforderungen der Puffercache verarbeiten kann, im Vergleich zu der Anzahl der eingehenden Anforderungen. Ein Cache-Treffer ist eine Anforderung, die erfolgreich verarbeitet wurde, und ein Miss ist eine Anforderung, die nicht erfolgreich verarbeitet wurde. Ein Miss wird über den Cache hinaus in das Dateisystem geleitet, um die Anforderung zu erfüllen.

Wenn Sie also 100 Cache-Treffer und 2 Fehler haben, haben Sie eine Cache-Treffer-Verhältnis von 100/102, was 98 % entspricht.

Für den normalen Betrieb von Postgres und Leistung sollten Sie eine Erfolgsquote für den Postgres-Cache von etwa 99 % haben.

Wenn Ihre Cache-Treffer-Verhältnis unter diesem Wert liegt, müssen Sie möglicherweise auf eine Instanz mit größerem Arbeitsspeicher wechseln.

Index erreicht¶

Das Hinzufügen von Indizes zu Ihrer Datenbank ist entscheidend für die Abfrage- und Anwendungsleistung. Indizes sind besonders nützlich für große Tabellen.

Die Index-Treffer-Rate wird als Verhältnis oder Prozentsatz der Gesamtzahl der Abfragen oder Abfrageausführungen, die einen Index erfolgreich nutzen, und der Gesamtzahl der ausgeführten Abfragen gemessen. Eine höhere Index-Treffer-Rate deutet auf eine bessere Index-Auslastung und eine bessere Abfrage-Gesamtleistung hin.

Im Allgemeinen werden Sie bei Tabellen, die größer als 10.000 Zeilen sind, nach 99 %+ suchen. Wenn Sie eine Tabelle sehen, die größer als 10.000 ist und keine oder nur geringe Indexnutzung hat, ist der beste Ausgangspunkt zum Hinzufügen eines Index.

Nicht verwendete Indizes¶

Nicht verwendete Indizes in PostgreSQL beziehen sich auf Indizes, die für Tabellen erstellt, aber nicht aktiv verwendet werden. Diese Indizes verbrauchen Speicherplatz, erfordern Wartung und können sich negativ auf die Performance auswirken.

Hier sind einige Gründe, warum Sie sich um nicht verwendete Indizes in Postgres kümmern sollten:

• Speicher und Festplattenplatz: Nicht verwendete Indizes belegen Speicherplatz, der besser für andere Zwecke genutzt werden könnte. Dies kann zu erhöhten Speicherkosten führen und den verfügbaren Speicherplatz für andere Datenbankobjekte reduzieren.

• Auswirkungen auf die Performance: Indizes verursachen bei Datenänderungsvorgängen wie Einfügungen, Aktualisierungen und Löschungen einen Overhead. Wenn es viele nicht genutzte Indizes gibt, dauern diese Vorgänge länger, da die Datenbank zusätzlich zur Tabelle mehrere Indizes aktualisieren muss.

• Langsamere Abfrageausführung: Die Abfrageoptimierung von Postgres berücksichtigt alle verfügbaren Indizes, wenn ein Ausführungsplan für eine Abfrage erstellt wird. Wenn nicht verwendete Indizes vorhanden sind, kann das Optimierungsprogramm zusätzliche Zeit für die Berücksichtigung dieser Indizes aufwenden, was zu suboptimalen Abfrageplänen und einer langsameren Abfrageausführung führt.

• Wartungsaufwand: Das Verwalten von Indizes erfordert Ressourcen, einschließlich CPU und Festplatten-E/A. Wenn Sie eine große Anzahl von nicht genutzten Indizes haben, werden diese Ressourcen durch unnötige Index-Wartungsaufgaben verschwendet.

Bloat¶

„Bloat“ bezieht sich auf die Anreicherung von toten und nicht genutzten Zeilen in einer Datenbank, die zum Verbrauch von Festplattenplatz und zu Performanceeinbußen führt. Die Änderung betrifft in erster Linie Datenbanken mit hoher transaktionalen Workloads. Das MVCC-System von Postgres erstellt mehrere Versionen einer Zeile, um gleichzeitige Transaktionen zu verarbeiten. Wenn eine Zeile aktualisiert oder gelöscht wird, wird eine neue Version erstellt, während die alte Version als „tot“ markiert wird. Diese toten Zeilen werden nicht sofort aus der Tabelle entfernt, um die Integrität der Transaktion zu wahren und die Datenkonsistenz bei gleichzeitigen Vorgängen sicherzustellen.

Um den von toten Zeilen belegten Speicherplatz wieder freizugeben, führt Postgres regelmäßig einen Vacuum-Vorgang durch. Dieser Prozess identifiziert und entfernt tote Zeilen aus der Tabelle, wodurch der Festplattenspeicher für die Wiederverwendung freigegeben wird. Ein Bloat tritt auf, wenn hohe Transaktionen eine erhebliche Anzahl von toten Zeilen zwischen Vacuum-Prozessen erzeugen.

Wir geben einen Prozentsatz von Bloat an, um die Menge an Speicherplatz anzuzeigen, die von toten Zeilen im Vergleich zur Gesamtgröße der Tabelle oder des Index belegt wird. Der angezeigte Bloat-Wert ist eine Schätzung oder Approximation. Wenn Sie mehr Daten-Bloat in Ihren Tabellen benötigen, können Sie die Erweiterung pgstattuple verwenden; dies kann jedoch ein ressourcenintensiver Vorgang sein.

Low Bloat: Ein Bloat-Wert unter 50 % wird im Allgemeinen als akzeptabel angesehen und erfordert normalerweise keine Maßnahmen. Es wird weiterhin empfohlen, Bloat auf weiteres Wachstum zu überwachen und die Vacuum-Konfigurationen und -Einstellungen zu überprüfen.

High Bloat: Ein Bloat-Wert von mehr als 50 % weist auf einen hohen Grad an Bloat hin, der die Performance und die Auslastung des Festplattenspeichers erheblich beeinträchtigen kann. Möglicherweise müssen Sie Maßnahmen in Betracht ziehen, wie z. B. die Durchführung eines manuellen Vacuum-Vorgangs oder die Änderung der Vakuumeinstellungen, wenn Sie langsame Abfragen oder Performanceprobleme feststellen.

Wir zeigen keinen Bloat-Status für Tabellen unter 1GB bzw. mit einem Bloat-Prozentsatz von weniger als 10 % an.

Ausreißerabfragen¶

Dies sind die Abfragen mit der höchsten proportionalen Ausführungszeit. Dazu können sowohl sehr langsame, aber relativ seltene Abfragen als auch etwas langsame, aber äußerst häufige Abfragen gehören. Die Abfragen mit der höchsten proportionalen Ausführungszeit sind der beste Ausgangspunkt für die Optimierung von Datenbankabfragen auf Anwendungsebene oder die Indizierung.

Zeitintensive Abfragen¶

Zeitintensive Abfragen in PostgreSQL können mehrfache negative Auswirkungen auf Ihre Datenbank und Anwendung haben. Hier sind einige Gründe, warum lang laufende Abfragen im Allgemeinen als unerwünscht angesehen werden:

• Auswirkungen auf die Performance: Zeitintensive Abfragen belegen Datenbankressourcen, einschließlich CPU, Arbeitsspeicher und Festplatten-E/A für einen längeren Zeitraum.

• Erhöhter Konflikt: Zeitintensive Abfragen können zu mehr Konflikten bei gemeinsam genutzten Ressourcen führen, z. B. bei Sperren und dem gleichzeitigen Zugriff auf Datenbankobjekte.

• Reduzierter Durchsatz: Wenn eine Abfrage relativ lange dauert, kann dies die Anzahl der Abfragen begrenzen, die innerhalb eines bestimmten Zeitrahmens ausgeführt werden können.

• Negative Benutzererfahrung: Wenn Ihre Anwendung auf eine rechtzeitige Ausführung von Abfragen angewiesen ist, können sich Abfragen mit langer Ausführungszeit negativ auf die Benutzererfahrung auswirken. Bei Benutzern kann es zu Verzögerungen oder einer fehlenden Reaktionsfähigkeit kommen, was zu Frustration und Unzufriedenheit mit Ihrer Anwendung beiträgt.

• Ressourcenerschöpfung: Zeitintensive Abfragen können übermäßig Arbeitsspeicher verbrauchen, was zu einer erhöhten Arbeitsspeichernutzung und möglichen Fehlern wegen Mangel an Arbeitsspeicher führt. Sie können auch große temporäre Dateien auf der Festplatte generieren, die möglicherweise Probleme mit dem Festplattenplatz verursachen.

Vacuum¶

Der Einblicksbereich enthält auch zudem Vacuum-Statistiken. Sie können die Namen der Tabellen, das letzte Vacuum und das letzte automatische Vacuum überprüfen. Sie können auch Einblicke darüber erhalten, wie viele tote Zeilen vorhanden sind, wann die Zeilen zuletzt durch Vacuum bereinigt wurden und vieles mehr.

Die Vacuum-Statistiken umfassen:

• Tabellenname

• Last vacuum: Zeitpunkt, an dem das letzte Mal ein manueller Vaccum-Vorgang durchgeführt wurde

• Last autovacuum: Zeitpunkt der letzten Ausführung des automatischen Vacuum

• Row count: Gesamtzeilenzahl für die Tabelle

• Dead row count: Anzahl der derzeit nicht durch Vacuum bereinigten/toten Zeilen in der Tabelle

• Scale factor: Der aktuelle Skalierungsfaktor, der in den Einstellungen für automatisches Vacuum eingestellt ist

• Threshold: Die Gesamtzahl der Zeilen, unter Verwendung des Skalierungsfaktors, die einen Vacuum-Vorgang erfordern

• Should vacuum: wenn ein manuelles Vacuum für die Tabelle erforderlich ist

Tabellengrößen¶

Details zu Ihren Postgres-Tabellengrößen finden Sie unter „Tabellengrößen“ in den Instanzeinblicken. Dies zeigt Tabelleninformationen wie:

• Tabellennamen

• ungefähre Zeilenzahl

• Gesamttabellengröße

• Größe der Indizes in der Tabelle

• Anzahl Tabellenbyte in TOAST-Tabellen

• Größe der Rohzeilen in Tabellen

Verbindungen¶

Der Verbindungsinformationen zeigt alle derzeit aktiven und inaktiven Verbindungen in der Datenbankinstanz an. Aktive Verbindungen befinden sich in einer Sitzung, die derzeit mit der Datenbank verbunden ist und eine Abfrage ausführt oder auf die Ausführung einer Abfrage wartet.

Leerlaufverbindungen sind üblich und stellen nicht per DROP ein Problem dar, aber sie können je nach Workload und Konfiguration zu einem Problem werden. Inaktive Verbindungen verbrauchen Speicher, sodass eine große Anzahl von Verbindungen zu einer übermäßigen Speichernutzung führen kann. Eine hohe Anzahl von im Leerlauf befindlichen Verbindungen ist in der Regel ein Anzeichen, dass die Datenbank von einem Verbindungspooling profitieren würde.

Jede laufende Sitzung hat eine pid, d. h. eine Prozess-ID. Dies ist ein eindeutiger Bezeichner, der jeder aktiven Backend-Verbindung zugewiesen wird.

Um eine Verbindung, Abfrage oder einen Prozess abzubrechen, aber die Sitzung offen zu lassen, verwenden Sie folgende Anweisung:

SELECT pg_cancel_backend(<pid>);

Eine stärkere Aktion, die die Verbindung schließt und alle Transaktionen zurücksetzt, ist:

SELECT pg_terminate_backend(<pid>);