Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

TOAST (The Oversized-Attribute Storage Technique) è una funzionalità di PostgreSQL progettata per gestire grandi valori di dati che superano la dimensione tipica dei blocchi di database di 8 KB. PostgreSQL non consente alle righe fisiche di estendersi su più blocchi. La dimensione del blocco funge da limite superiore alla dimensione delle righe. TOAST supera questa restrizione suddividendo i valori di campo di grandi dimensioni in blocchi più piccoli. Li memorizza separatamente in una tabella TOAST dedicata collegata alla tabella principale. Per ulteriori informazioni, consulta il meccanismo di archiviazione TOAST di PostgreSQL e la documentazione di implementazione.

Comprendere le operazioni TOAST

TOAST esegue la compressione e memorizza valori di campo di grandi dimensioni fuori linea. TOAST assegna un OID (Object Identifier) univoco a ogni blocco di dati di grandi dimensioni archiviato nella tabella TOAST. La tabella principale memorizza l'ID del valore TOAST e l'ID della relazione sulla pagina per fare riferimento alla riga corrispondente nella tabella TOAST. Ciò consente a PostgreSQL di localizzare e gestire in modo efficiente questi blocchi TOAST. Tuttavia, man mano che la tabella TOAST cresce, il sistema rischia di esaurire le risorse disponibili OIDs, con conseguente peggioramento delle prestazioni e potenziali tempi di inattività dovuti all'esaurimento degli OID.

Identificatori di oggetti in TOAST

Un Object Identifier (OID) è un identificatore univoco a livello di sistema utilizzato da PostgreSQL per fare riferimento a oggetti del database come tabelle, indici e funzioni. Questi identificatori svolgono un ruolo fondamentale nelle operazioni interne di PostgreSQL, consentendo al database di localizzare e gestire gli oggetti in modo efficiente.

Per le tabelle con set di dati idonei per il toast, PostgreSQL assegna l'identificazione univoca di ogni blocco di dati di OIDs grandi dimensioni archiviato nella tabella TOAST associata. Il sistema associa ogni blocco a unchunk_id, che aiuta PostgreSQL a organizzare e localizzare questi blocchi in modo efficiente all'interno della tabella TOAST.

Identificazione delle sfide prestazionali

La gestione degli OID di PostgreSQL si basa su un contatore globale a 32 bit, che viene eseguito dopo aver generato 4 miliardi di valori univoci. Sebbene il cluster di database condivida questo contatore, l'allocazione OID prevede due passaggi durante le operazioni TOAST:

Il peggioramento delle prestazioni può verificarsi quando:

Per ulteriori informazioni, consulta i limiti di dimensione della tabella TOAST di PostgreSQL e la documentazione sull'allocazione OID:

Un contatore globale genera OIDs e riassume ogni 4 miliardi di valori, in modo che di tanto in tanto il sistema generi nuovamente un valore già utilizzato. PostgreSQL lo rileva e riprova con l'OID successivo. Un INSERT lento potrebbe verificarsi se c'è una serie molto lunga di valori OID usati senza spazi vuoti nella tabella TOAST. Queste problematiche diventano più evidenti man mano che lo spazio OID si riempie, con conseguente rallentamento degli inserimenti e degli aggiornamenti.

Identificazione del problema

Isolamento del problema

Raccomandazioni

I seguenti approcci possono aiutare a risolvere i problemi di contesa di TOAST OID.

Monitoraggio

Utilizzo delle tabelle di sistema

È possibile utilizzare le tabelle di sistema di PostgreSQL per monitorare la crescita dell'utilizzo degli OID.

Il seguente blocco anonimo conta il numero di elementi distinti OIDs utilizzati in ogni tabella TOAST e visualizza le informazioni della tabella principale:

DO $$
DECLARE
    r record;
    o bigint;
    parent_table text;
    parent_schema text;
BEGIN
    SET LOCAL client_min_messages TO notice;
    FOR r IN
    SELECT
        c.oid,
        c.oid::regclass AS toast_table
    FROM
        pg_class c
    WHERE
        c.relkind = 't'
        AND c.relowner != 10 LOOP
            -- Fetch the number of distinct used OIDs (chunk IDs) from the TOAST table
            EXECUTE 'SELECT COUNT(DISTINCT chunk_id) FROM ' || r.toast_table INTO o;
            -- If there are used OIDs, find the associated parent table and its schema
            IF o <> 0 THEN
                SELECT
                    n.nspname,
                    c.relname INTO parent_schema,
                    parent_table
                FROM
                    pg_class c
                    JOIN pg_namespace n ON c.relnamespace = n.oid
                WHERE
                    c.reltoastrelid = r.oid;
                -- Raise a concise NOTICE message
                RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Number of used OIDs: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
            END IF;
        END LOOP;
END
$$;

Esempio di output che mostra le statistiche sull'utilizzo di OID tramite la tabella TOAST:

NOTICE:  Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Number of used OIDs: 45,623,317
NOTICE:  Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Number of used OIDs: 10,000
NOTICE:  Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Number of used OIDs: 1,000,000
DO

Il seguente blocco anonimo recupera l'OID massimo assegnato per ogni tabella TOAST non vuota:

DO $$
DECLARE
    r record;
    o bigint;
    parent_table text;
    parent_schema text;
BEGIN
    SET LOCAL client_min_messages TO notice;
    FOR r IN
    SELECT
        c.oid,
        c.oid::regclass AS toast_table
    FROM
        pg_class c
    WHERE
        c.relkind = 't'
        AND c.relowner != 10 LOOP
            -- Fetch the max(chunk_id) from the TOAST table
            EXECUTE 'SELECT max(chunk_id) FROM ' || r.toast_table INTO o;
            -- If there's at least one TOASTed chunk, find the associated parent table and its schema
            IF o IS NOT NULL THEN
                SELECT
                    n.nspname,
                    c.relname INTO parent_schema,
                    parent_table
                FROM
                    pg_class c
                    JOIN pg_namespace n ON c.relnamespace = n.oid
                WHERE
                    c.reltoastrelid = r.oid;
                -- Raise a concise NOTICE message
                RAISE NOTICE 'Parent schema: % | Parent table: % | Toast table: % | Max chunk_id: %', parent_schema, parent_table, r.toast_table, TO_CHAR(o, 'FM9,999,999,999,999');
            END IF;
        END LOOP;
END
$$;

Esempio di output che mostra il blocco massimo per le tabelle IDs TOAST:

NOTICE:  Parent schema: public | Parent table: my_table | Toast table: pg_toast.pg_toast_16559 | Max chunk_id: 45,639,907
NOTICE:  Parent schema: public | Parent table: my_table1 | Toast table: pg_toast.pg_toast_45639925 | Max chunk_id: 45,649,929
NOTICE:  Parent schema: public | Parent table: my_table2 | Toast table: pg_toast.pg_toast_45649931 | Max chunk_id: 46,649,935
DO

Uso di Approfondimenti sulle prestazioni

Gli eventi LWLock:buffer_io di attesa LWLock:OidGenLock vengono visualizzati in Performance Insights durante le operazioni che richiedono l'assegnazione di nuovi identificatori di oggetti ()OIDs. Le sessioni AAS (High Average Active Sessions) per questi eventi in genere indicano situazioni di conflitto durante l'assegnazione degli OID e la gestione delle risorse. Ciò è particolarmente comune in ambienti con un elevato tasso di abbandono dei dati, un utilizzo esteso di grandi quantità di dati o la creazione frequente di oggetti.

LWLockCiò è particolarmente comune in ambienti con un elevato tasso di abbandono dei dati, un ampio utilizzo di dati o la creazione frequente di oggetti. ----sep----:buffer_io

LWLock:buffer_ioè un evento di attesa che si verifica quando una sessione PostgreSQL è in I/O attesa del completamento delle operazioni su un buffer condiviso. Ciò si verifica in genere quando il database legge i dati dal disco alla memoria o scrive pagine modificate dalla memoria al disco. L'evento di BufferIO attesa garantisce la coerenza impedendo a più processi di accedere o modificare lo stesso buffer mentre I/O le operazioni sono in corso. Un numero elevato di occorrenze di questo evento di attesa può indicare colli di bottiglia sul disco o un'attività eccessiva I/O nel carico di lavoro del database.

Durante le operazioni TOAST:

La dimensione dell'indice influisce direttamente sul numero di pagine buffer a cui è necessario accedere durante queste operazioni. Anche se l'indice non è gonfio, le sue dimensioni possono aumentare l'I/O del buffer, in particolare in ambienti con elevata concorrenza o elevato tasso di abbandono. Per ulteriori informazioni, consulta:Guida alla risoluzione dei problemi relativi agli eventi Bufferio wait. LWLock

LWLock:OidGenLock

OidGenLockè un evento di attesa che si verifica quando una sessione PostgreSQL è in attesa di allocare un nuovo identificatore di oggetto (OID). Questo blocco garantisce che OIDs vengano generati in modo sequenziale e sicuro, consentendo la generazione di un solo processo alla volta. OIDs

Durante le operazioni TOAST:

Fattori aggiuntivi che aumentano la contesa OID: