Gestione di un numero elevato di oggetti in PostgreSQL

Autovacuum può avere difficoltà a tenere il passo con la crescita degli ID delle transazioni o l'aumento dei tavoli a causa della mancanza di lavoratori rispetto alla quantità di lavoro.

Azione consigliata: Esistono diversi fattori per ottimizzare l'autovacuum in modo che stia al passo con un determinato numero di tabelle e un determinato carico di lavoro. Vedi autovacuum per suggerimenti su come determinare le impostazioni di autovacuum appropriate. Usa postgres_get_av_diag postgres_get_av_diag per monitorare i problemi relativi alla crescita degli ID delle transazioni.

Amazon RDS utilizza l'opzione «--link» durante l'esecuzione di pg_upgrade per evitare di dover fare copie dei file di dati, i metadati dello schema devono comunque essere ripristinati nella nuova versione del database. Anche con parallel pg_restore, se esiste un numero significativo di relazioni, ciò aumenterà la quantità di tempi di inattività.

Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Ogni tabella e le colonne associate verranno aggiunte alle pg_attribute pg_depend tabelle utilizzate di frequente nelle normali operazioni del database. pg_class Non sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.

Azione consigliata: controlla regolarmente il gonfiamento della tabella per queste tabelle specifiche e occasionalmente esegui un errore VACUUM FULL su queste tabelle specifiche. Tieni presente che VACUUM FULL sulle tabelle del catalogo è necessario un ACCESS EXCLUSIVE blocco, il che significa che nessun'altra interrogazione potrà accedervi fino al completamento dell'operazione.

Le tabelle temporanee non vengono cancellate dall'autovacuum, ma rimarranno invariate per tutta la durata della loro esistenza e, se non vengono IDs rimosse, possono causare problemi.

Azione consigliata: le tabelle temporanee resteranno attive per tutta la durata della sessione che le ha create o possono essere eliminate manualmente. Una buona pratica per evitare transazioni di lunga durata con tabelle temporanee impedirà a queste tabelle di contribuire alla crescita massima degli ID di transazione utilizzati.

Degrado generale delle prestazioni dovuto alle dimensioni del catalogo. Quando le sessioni creano ed eliminano continuamente tabelle temporanee, si aggiungono pg_class alle pg_attribute pg_depend tabelle utilizzate di frequente nelle normali operazioni del database. Non sarà visibile un evento di attesa specifico, ma l'efficienza del buffer condiviso ne risentirà.

Azione consigliata:

Le tabelle non registrate generalmente non sono incluse nella replica logica, incluse le , poiché la replica logica si basa sul WAL per acquisire e trasferire le modifiche. Scopri di più su come configurare Aurora PostgreSQL per replicare tabelle non registrate.

È possibile accedere alle tabelle non registrate solo dal nodo writer nel cluster Aurora DB. Per tutti i dettagli, consulta Lavorare con tabelle non registrate in Aurora PostgreSQL.

A volte il sovraccarico di tempo di pianificazione aumenta e la spiegazione dei piani per le domande diventa più complicata, rendendo difficile l'identificazione delle opportunità di ottimizzazione. Per le versioni di PostgreSQL precedenti alla 18, molte partizioni con un carico di lavoro elevato possono causare attese. LWLock:LockManager

Azione consigliata: Determina un numero minimo di partizioni che ti consenta di completare l'organizzazione dei dati e allo stesso tempo di fornire un'esecuzione delle query efficiente.

Un numero molto elevato di partizioni introdurrà difficoltà di manutenzione come la precreazione e la rimozione. Autovacuum tratterà le partizioni come normali relazioni e dovrà eseguire una pulizia regolare, richiedendo quindi un numero sufficiente di lavoratori per completare l'operazione.

Azione consigliata:

I file temporanei sono una parte necessaria di PostgreSQL quando i risultati delle query non sono in grado di adattarsi a work_mem. In genere va bene. Tuttavia, quando il carico di lavoro lo utilizza in modo estensivo, ciò indica che le query di grandi dimensioni vengono continuamente eseguite e si osserverà una diminuzione di. FreeLocalStorage Per maggiori dettagli, consulta Gestione dei file temporanei.

Se prevedi di utilizzare Blue/Green Deployments per qualsiasi tipo di modifica o aggiornamento della configurazione, è importante comprendere l'impatto di un numero elevato di sequenze sullo switchover. Una delle ultime fasi di uno switchover sincronizzerà il valore corrente delle sequenze e, se ce ne sono diverse migliaia, ciò aumenterà il tempo complessivo di passaggio.

Azione consigliata: se il carico di lavoro del database consentisse l'uso di un UUID condiviso anziché di un sequence-per-table approccio, ciò ridurrebbe la fase di sincronizzazione durante lo switchover.

Gli oggetti di grandi dimensioni non vengono attualmente replicati in PostgreSQL durante la replica logica. Per saperne di più, consulta la pagina Restrizioni nella documentazione di PostgreSQL. In una configurazione , ciò significa che gli oggetti di grandi dimensioni nell'ambiente blu non vengono replicati nell'ambiente verde.

Un aggiornamento può esaurire la memoria e fallire se sono presenti milioni di oggetti di grandi dimensioni e l'istanza non è in grado di gestirli durante l'aggiornamento. Il processo di aggiornamento della versione principale di PostgreSQL comprende due ampie fasi: il dumping dello schema tramite pg_dump e il ripristino tramite pg_restore. Se il tuo database ha milioni di oggetti di grandi dimensioni, devi assicurarti che l'istanza abbia memoria sufficiente per gestire pg_dump e pg_restore durante un aggiornamento e ridimensionarla su un tipo di istanza più grande.