Langsame Datenbankleistung

Die typischen Symptome dieses Problems sind folgende:

• Hohe Festplatten-E/A (Eingabe/Ausgabe) oder Speicherauslastung
• Langsame Abfragen

Die häufigste Ursache sind langsame Abfragen, die untersucht werden. Führen Sie die folgenden Schritte aus, um festzustellen, ob dies der Fall ist:

1. Liste der lang laufenden Abfragen:

   select age(now(),query_start), pid, client_addr, state, substring(query,0,80) from pg_stat_activity where state != 'idle' order by 1 desc;
   

2. Abfrageblockierung validieren:

   select pg_blocking_pids(pid), pid AS blocked_pid, state, query, age(now(),query_start) AS duration from pg_stat_activity where array_length(pg_blocking_pids(pid),1) > 0 order by 1,2;
   

3. Überprüfen Sie den Abfrageausführungsplan:

   Explain <query>;
   

4. Überprüfen Sie, ob Datenbankstatistiken fehlen. Verwenden Sie die folgende Abfrage zur Validierung: Aktion > Analysieren ausführen Alternativ können Sie den folgenden Befehl ausführen:

   Analyze <tablename>  select relname, n_live_tup, n_dead_tup, last_vacuum,last_autovacuum,last_analyze,last_autoanalyze, analyze_count,autoanalyze_count from pg_stat_all_tables where schemaname='public';
   

5. Überprüfen Sie, ob der Index in der Tabelle fehlt. PostgreSQL bietet Indexmethoden wie B-Tree, Hash, GiST,SP-GiST, GIN und BRIN. Verwenden Sie eine dieser Methoden, um den Index zu erstellen.

6. Überprüfen Sie, ob die Tabelle aufgebläht ist. Führen Sie die folgende Abfrage zur Validierung aus. Aktion > Staubsauger laufen lassen

   Alternativ können Sie die folgende Anweisung verwenden:

   SELECT
   relname AS table_name,
   pg_size_pretty(pg_relation_size(c.oid)) AS actual_size,
   pg_size_pretty(
   CASE
   WHEN c.relpages = 0 THEN 0
   ELSE (pg_relation_size(c.oid) - (c.relpages *
   (current_setting('block_size')::numeric - 24))) * 100 / pg_relation_size(c.oid)
   END
   ) AS bloat_percentage, pg_size_pretty(
   CASE
   WHEN c.relpages = 0 THEN 0
   ELSE (pg_relation_size(c.oid) - (c.relpages *
   (current_setting('block_size')::numeric - 24)))
   END
   )AS bloat_size
   FROM pg_class c
   LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
   WHERE relkind = 'r' AND n.nspname = 'public' -- Adjust schema if needed
   ORDER BY bloat_size DESC NULLS LAST;
   

7. Überprüfen Sie, ob die Datenbank oder Objekte mit pg_dump oder erstellt pg_restore wurden. Verwenden Sie „Aktion > Statistiken aktualisieren“, um die Daten zu aktualisieren.

8. Stellen Sie sicher, dass ausreichend work_mem zugewiesen ist, wenn die Abfrage einen Sortiervorgang durchführt.

9. Verwenden Sie pg_stat Anweisungen, um die folgenden Informationen zu ermitteln:

   • Durchschnittliche Ausführungszeit und Anzahl der Aufrufe abfragen

   • CPU-Auslastung durch die Abfragen in Prozent

   • Speicherauslastung durch die Abfragen in Prozent

pg_stat_activity, pg_stat_bgwriter, und pg_buffercache sind wichtige Werkzeuge in PostgreSQL zur Überwachung und zum Verständnis der Datenbankleistung.

Überwachung der Bereitstellung und Überwachung der Datenbankauslastung

Databases for PostgreSQL bereitstellungen bieten eine Integration mit dem IBM Cloud Monitoring dienst zur Überwachung der Ressourcennutzung in Ihrer Einrichtung. Verwenden Sie diesen Dienst, um Ihre Bereitstellung (Festplatte und Arbeitsspeicher) und Ihre Datenbankauslastung zu überwachen.

Verwenden Sie Cloud Databases Dashboards, um Warnmeldungen für Schwellenwerte für CPU, Arbeitsspeicher und Festplatten-IOPS festzulegen. Viele der verfügbaren Metriken, wie Festplattennutzung und IOPS, sind nützlich für die Konfiguration der automatischen Skalierung in Ihrer Einrichtung. Die automatische Skalierung ist standardmäßig nicht aktiviert, daher müssen Sie sie manuell konfigurieren.

Die Beobachtung von Trends in der Nutzung und die Konfiguration der automatischen Skalierung, um auf diese Trends zu reagieren, können dazu beitragen, Leistungsprobleme zu beheben, bevor Ihre Datenbanken aufgrund von Ressourcenerschöpfung instabil werden. Beispielsweise Änderungen bei der Festplatten-E/A oder CPU- oder Speicherfehlern, die zu Leistungsproblemen führen.

E/A-Operationen der Platte pro Sekunde

Die Anzahl der Ein-/Ausgabevorgänge pro Sekunde (IOPS) ist durch die Art und Größe des Speichermediums begrenzt. Speichervolumen für Databases for PostgreSQL Bereitstellungen werden auf Block Storage Endurance Volumes in der Stufe 10 IOPS pro GB bereitgestellt.

Wenn Ihre Betriebslast gesättigt ist oder die IOPS-Grenze überschreitet, werden Datenbankanfragen und -operationen verzögert, bis das Speichersubsystem den Rückstand aufholen kann. Längere Zeiträume mit hoher Last können dazu führen, dass Ihre Bereitstellung keine Abfragen mehr verarbeiten kann und effektiv nicht mehr verfügbar ist. Sie können die Anzahl der für Ihren Einsatz verfügbaren IOPS erhöhen, indem Sie die Festplattengröße vergrößern. Beispielsweise können Sie bei 10 IOPS pro GB-Tier die IOPS durch Erhöhen der Volumengröße steigern.

Selbst eine längere Auslastung der Festplatte von 40 bis 50 % kann sich erheblich negativ auf die Datenbankleistung auswirken. Weisen Sie für Produktionsumgebungen mindestens 100 GB (1.000 IOPS) zu. IOPS = 10 × zugewiesene GB (zum Beispiel 100 GB = 1.000 IOPS)

Speicherbelegung

Der Arbeitsspeicher ist die schnellste und effizienteste Methode, um auf Daten zuzugreifen und diese zu verarbeiten. Aus diesem Grund arbeitet eine Datenbank fast immer schneller, wenn sie den Arbeitsspeicher nutzt, anstatt Daten von der Festplatte zu lesen. Es gibt noch weitere Kennzahlen, die zu betrachten und zu berücksichtigen sind, wie Cache-Treffer, gelesene Blöcke und getroffene Blöcke. Die bloße Anzeige einer Speicherauslastung von 100 % ist an sich noch kein Grund zur Sorge. Wenn der Speicher erschöpft ist und Auslagerungsseiten verwendet werden, kann die Leistung erheblich beeinträchtigt werden.

Sie können die Menge des Speichers, der für den gemeinsamen Pufferpool der Datenbank bestimmt ist, einstellen, indem Sie shared_buffers in Ihrer Databases for PostgreSQL Konfiguration anpassen. Der empfohlene Höchstwert liegt bei 25 % des Gesamtspeichers der Einrichtung. Wenn dem gemeinsamen Pufferpool zu viel Speicher zugewiesen wird, kann dies dazu führen, dass dem System Speicher für andere Zwecke fehlt, dass die Leistung beeinträchtigt wird oder dass die Datenbank möglicherweise sogar deaktiviert wird.

Überwachung der Datenbankauslastung

Sie haben zwei Möglichkeiten, die Datenbankauslastung zu überprüfen:

{

source logs|filter message.attr.durationMillis>=1000

}

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT username, database, queryid, query_preview, calls, total_exec_time, pct_exec_time, ROUND(SUM(pct_exec_time) OVER (ORDER BY total_exec_time DESC)) AS cum_pct_exec_time, avg_exec_time FROM ( SELECT pu.usename AS username, pd.datname AS database, pss.queryid, LEFT(pss.query, 50) AS query_preview, pss.calls, ROUND(pss.total_exec_time::numeric, 3) AS total_exec_time, ROUND((100.0 * pss.total_exec_time / SUM(pss.total_exec_time) OVER ())::numeric, 2) AS pct_exec_time, ROUND(pss.mean_exec_time::numeric, 3) AS avg_exec_time FROM pg_stat_statements pss JOIN pg_user pu ON pss.userid = pu.usesysid JOIN pg_database pd ON pss.dbid = pd.oid ) AS subquery ORDER BY total_exec_time DESC LIMIT 25;

SELECT
   username,
   database,
   queryid,
   query_preview,
   calls,
   pct_calls,
   ROUND(SUM(pct_calls) OVER (ORDER BY calls DESC)) AS cum_pct_calls,
   total_exec_time,
   avg_exec_time
FROM (
   SELECT
      pu.usename AS username,
      pd.datname AS database,
      pss.queryid,
      LEFT(pss.query, 50) AS query_preview,
      pss.calls,
      ROUND(100.0 * pss.calls / SUM(pss.calls) OVER (), 2) AS pct_calls,
      ROUND(pss.total_exec_time::numeric, 3) AS total_exec_time,
      ROUND(pss.mean_exec_time::numeric, 3) AS avg_exec_time
   FROM
      pg_stat_statements pss
      JOIN pg_user pu ON pss.userid = pu.usesysid
      JOIN pg_database pd ON pss.dbid = pd.oid
) AS subquery
ORDER BY
   calls DESC
LIMIT 25;

SELECT query, calls, total_exec_time/calls as avg_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Weitere Maßnahmen, die Sie zur Leistungssteigerung ergreifen können

Zur Fehlerbehebung bei Leistungsproblemen können Sie auch die folgenden Maßnahmen in Betracht ziehen:

• Optimieren Sie langsame Abfragen

  • Führen Sie EXPLAIN (ANALYZE, BUFFERS) für langsame Abfragen aus. Dies zeigt, wie die Datenbank die Abfrage ausführt und wo sie langsam ist. Zum Beispiel:

  EXPLAIN (ANALYZE, BUFFERS)
  SELECT * FROM student WHERE student_id = 12345;
  

  • Suchen Sie nach:

    • Abfragen, die viel Speicher oder Festplattenspeicher beanspruchen

    • Fügen Sie IBM Cloud nach Bedarf Ressourcen hinzu

    • Skalieren Sie die Festplatte/den Arbeitsspeicher für höhere IOPS und mehr Arbeitsspeicher

• Fehlende oder ineffiziente Indizes sind eine häufige Ursache für langsame Abfragen. Verwenden Sie EXPLAIN, um sequenzielle Scans zu identifizieren, und erwägen Sie das Hinzufügen von Indizes.

• Führen Sie VACUUM aus, um die Analyse des Datenbankzustands zu unterstützen.

• Ziehen Sie die Verwendung von Verbindungspooling in Betracht, um mehr Verbindungen zu verarbeiten. Databases for PostgreSQL setzt die maximale Anzahl von Verbindungen zu Ihrer Databases for PostgreSQL Datenbank auf 115. 15 Verbindungen sind für den Superuser reserviert, um den Zustand und die Integrität Ihrer Datenbank aufrechtzuerhalten, und 100 Verbindungen sind für Sie und Ihre Anwendungen verfügbar. Nachdem das Verbindungslimit erreicht ist, führen alle Versuche, eine neue Verbindung aufzubauen, zu einem Fehler. Um zu verhindern, dass Ihre Bereitstellung von Verbindungen überflutet wird, verwenden Sie Verbindungspooling oder skalieren Sie Ihre Bereitstellung und erhöhen Sie ihre Verbindungsbegrenzung. Weitere Informationen finden Sie unter Verwalten von PostgreSQL Verbindungspools.

• Überprüfen Sie, ob irgendwelche Rezepte Backups und Batch-Uploads von Daten ausführen, zum Beispiel: Automatische Backups werden täglich durchgeführt und gemäß einem einfachen Aufbewahrungsplan von 30 Tagen gespeichert. Wenn eine Sicherung hängen geblieben ist, können Sie den Abschnitt „Verfügbare Sicherungen“ überprüfen und die hängengebliebene Sicherung auf der Cloud-UI-Seite der Datenbankinstanz identifizieren.

• Überprüfen Sie Ihre IBM Cloud Benachrichtigungen auf Wartungsarbeiten. Beispielsweise das Patchen von Datenbanken.

• Wenn Sie glauben, dass es sich um ein Plattformproblem wie z. B. Wartungsarbeiten handelt, wenden Sie sich bitte mit der Datenbank-CRN an IBM den Support.