AlloyDB Omni-Datenbankleistung überwachen

Wählen Sie eine Dokumentationsversion aus: 16.3.0

• Aktuell (16.8.0)
• 16.8.0
• 16.3.0
• 15.12.0
• 15.7.1
• 15.7.0

Hinweis:Ihre Nutzung von AlloyDB Omni unterliegt der Vereinbarung zwischen Ihnen und Google, die für Google Cloud -Angebote gilt. Wenn Sie kein Google Cloud-Konto haben oder keine Vereinbarung mit Google getroffen haben, die Google Cloud-Angebote regelt, fahren Sie bitte nicht fort und laden Sie diese Software erst herunter, wenn Sie dies getan haben. Informationen zum Erstellen eines Google Cloud -Kontos finden Sie auf der Google Cloud -Startseite.

Auf dieser Seite wird beschrieben, wie Sie die Leistung Ihrer AlloyDB Omni-Datenbank mit PostgreSQL-Beobachtbarkeitsskripten überwachen können.

Status verbundener Prozesse und Warteereignisse ansehen

Sie können alle Prozesse, die mit Ihrer AlloyDB Omni-Instanz verbunden sind, sowie alle Back-Ends, die auf Aktivität warten, ermitteln, indem Sie die Ansicht pg_stat_activity abfragen.

SELECT
    pid,
    datname,
    age(backend_xid) AS age_in_xids,
    now() - xact_start AS xact_age,
    now() - query_start AS query_age,
    state,
    wait_event_type,
    wait_event,
    query_id,
    query
FROM
    pg_stat_activity
WHERE
    state != 'idle'
    AND pid <> pg_backend_pid()
ORDER BY
    4 DESC
LIMIT 10;

Größte Tabellen ansehen

Sie können die Größe Ihrer größten Tabellen ermitteln, indem Sie die Ansicht pg_stat_user_tables abfragen.

SELECT
    oid,
    oid::regclass table_name,
    pg_size_pretty(pg_relation_size(oid)),
    relpages,
    s.seq_scan,
    s.idx_scan
FROM
    pg_class,
    pg_stat_user_tables s
WHERE
    s.relid = oid
    AND oid > 16383
    AND relpages > 100
    AND relkind = 'r'
ORDER BY
    relpages DESC
LIMIT 20;

Häufigste sequenzielle Scans ansehen

Sie können die wichtigsten sequenziellen Scans abrufen, indem Sie die Ansicht pg_stat_user_tables abfragen.

SELECT
    relid,
    relname,
    seq_scan,
    pg_size_pretty(pg_relation_size(relid))
FROM
    pg_stat_user_tables
ORDER BY
    seq_scan DESC
LIMIT 15;

Häufigste Indexscans ansehen

Sie können die wichtigsten Indexscans abrufen, indem Sie die Ansicht pg_stat_user_tables abfragen.

SELECT
    relid,
    relid::regclass table_name,
    idx_scan,
    pg_size_pretty(pg_relation_size(relid))
FROM
    pg_stat_user_tables
WHERE
    idx_scan > 10
ORDER BY
    idx_scan DESC
LIMIT 15;

Am längsten laufende Transaktionen ansehen

Sie können die am längsten laufenden Transaktionen abfragen, indem Sie die Ansicht pg_stat_activity abfragen und das Alter der Transaktion prüfen.

SELECT
    pid,
    age(backend_xid) AS age_in_xids,
    now() - xact_start AS xact_age,
    now() - query_start AS query_age,
    state,
    query
FROM
    pg_stat_activity
WHERE
    state != 'idle'
ORDER BY
    2 DESC
LIMIT 10;

Fortschritt des Staubsaugens prüfen

Sie können den Fortschritt von VACUUM-Vorgängen prüfen, indem Sie die Ansicht pg_stat_progress_vacuum abfragen und sie mithilfe von Prozess-IDs mit der Ansicht pg_stat_activity verknüpfen.

SELECT
  p.pid,
  now() - a.xact_start AS duration,
  coalesce(wait_event_type ||'.'|| wait_event, 'f') AS waiting,
  CASE
    WHEN a.query ~*'^autovacuum.*to prevent wraparound' THEN 'wraparound'
    WHEN a.query ~*'^vacuum' THEN 'user'
  ELSE
    'regular'
  END AS mode,
  p.datname AS database,
  p.relid::regclass AS table,
  p.phase,
  pg_size_pretty(p.heap_blks_total * current_setting('block_size')::int) AS table_size,
  pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
  pg_size_pretty(p.heap_blks_scanned * current_setting('block_size')::int) AS scanned,
  pg_size_pretty(p.heap_blks_vacuumed * current_setting('block_size')::int) AS vacuumed,
  round(100.0 * p.heap_blks_scanned / p.heap_blks_total, 1) AS scanned_pct,
  round(100.0 * p.heap_blks_vacuumed / p.heap_blks_total, 1) AS vacuumed_pct,
  p.index_vacuum_count,
  round(100.0 * p.num_dead_tuples / p.max_dead_tuples,1) AS dead_pct
FROM pg_stat_progress_vacuum p
JOIN pg_stat_activity a using (pid)
ORDER BY now() - a.xact_start DESC;

Asynchrone Abfragen ansehen

Wenn Sie asynchron ausgeführte Abfragen aufrufen möchten, können Sie die Ansicht pg_stat_activity abfragen und nach Abfragen filtern, die nicht der Leader-Prozess sind.

SELECT
    query,
    leader_pid,
    array_agg(pid) FILTER (WHERE leader_pid != pid) AS members
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL
GROUP BY
    query,
    leader_pid;

SQL für Blockierungssperre ansehen

Sie können blockierte Aktivitäten aufrufen, indem Sie die Ansicht pg_locks abfragen und mit der Ansicht pg_stat_activity verknüpfen.

SELECT blocked_locks.pid     AS blocked_pid,
       blocked_activity.usename  AS blocked_user,
       blocking_locks.pid     AS blocking_pid,
       blocking_activity.usename AS blocking_user,
       blocked_activity.query    AS blocked_statement,
       blocked_activity.wait_event AS blocked_wait_event,
       blocking_activity.wait_event AS blocking_wait_event,
       blocking_activity.query   AS current_statement_in_blocking_process
 FROM  pg_catalog.pg_locks         blocked_locks
  JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
  JOIN pg_catalog.pg_locks         blocking_locks
      ON blocking_locks.locktype = blocked_locks.locktype
      AND blocking_locks.database IS NOT DISTINCT FROM blocked_locks.database
      AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
      AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
      AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
      AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
      AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
      AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
      AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
      AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
      AND blocking_locks.pid != blocked_locks.pid
  JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
 WHERE NOT blocked_locks.granted;

Effektivität von work_mem- und temp_buffers-Größen ermitteln

Wenn Sie herausfinden möchten, ob work_mem und temp_buffers die richtige Größe für Ihre Anforderungen haben, können Sie die Ansicht pg_stat_database abfragen und die Datei postgres.log prüfen. Führen Sie mit pg_stat_database die folgende Abfrage aus. Wenn zwischen den Ausführungen ein Anstieg bei temp_files oder temp_bytes zu beobachten ist, ist wahrscheinlich eine Optimierung für work_mem oder temp_buffers erforderlich.

SELECT
    datname,
    temp_files,
    temp_bytes
FROM
    pg_stat_database;

Prüfen Sie nach der Ausführung die Datei postgres.log, um zu sehen, ob temporäre Dateien verwendet wurden:

LOG: [fd.c:1772] temporary file: path "base/pgsql_tmp/pgsql_tmp4640.1", size 139264

Ziel ist es, die Erstellung temporärer Dateien zu minimieren, nicht vollständig zu verhindern. Das Festlegen von work_mem und temp_buffers ist ein Kompromiss zwischen dem verfügbaren Arbeitsspeicher auf dem Host und der Anzahl der Verbindungen, für die der Arbeitsspeicher erforderlich ist. Um diese Parameter richtig festzulegen, müssen Sie die einzelnen Arbeitslasten kennen.