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à.

Concetti essenziali per l'ottimizzazione di Aurora PostgreSQL

Prima di sintonizzare il database Aurora PostgreSQL, assicurati di sapere cosa sono gli eventi di attesa e perché si verificano. Esamina anche l'architettura di base della memoria e del disco di Aurora PostgreSQL. Per un utile diagramma architettonico, vedere il wikibook PostgreSQL.

Eventi di attesa Aurora PostgreSQL

Un evento di attesa indica una risorsa per la quale è in attesa di una sessione. Ad esempio, l'evento di attesa Client:ClientRead si verifica quando Aurora PostgreSQL è in attesa di ricevere dati dal client. Le risorse tipiche che una sessione attende includono quanto segue:

Ad esempio, per soddisfare una query, la sessione potrebbe eseguire una scansione completa della tabella. Se i dati non sono già in memoria, la sessione attende il completamento dell'I/O del disco. Quando i buffer vengono letti in memoria, potrebbe essere necessario attendere perché altre sessioni accedono agli stessi buffer. Il database registra le attese utilizzando un evento di attesa predefinito. Questi eventi sono raggruppati in categorie.

Un evento di attesa non mostra di per sé un problema di prestazioni. Ad esempio, se i dati richiesti non sono in memoria, è necessaria la lettura dei dati dal disco. Se una sessione blocca una riga per un aggiornamento, un'altra sessione attende che la riga venga sbloccata in modo che possa aggiornarla. Un commit richiede di attendere il completamento della scrittura su un file di registro. Le attese sono parte integrante del normale funzionamento di un database.

Un gran numero di eventi di attesa in genere mostrano un problema di prestazioni. In questi casi, è possibile utilizzare i dati degli eventi di attesa per determinare dove stanno trascorrendo il tempo delle sessioni. Ad esempio, se un report che in genere viene eseguito in minuti ora viene eseguito per ore, è possibile identificare gli eventi di attesa che contribuiscono maggiormente al tempo di attesa totale. Se è possibile determinare le cause degli eventi di attesa principali, a volte è possibile apportare modifiche che migliorano le prestazioni. Ad esempio, se la sessione è in attesa su una riga bloccata da un'altra sessione, è possibile terminare la sessione di blocco.

Memoria Aurora PostgreSQL

La memoria Aurora PostgreSQL è divisa in condivisa e locale.

Memoria condivisa in Aurora PostgreSQL

Aurora PostgreSQL assegna memoria condivisa all'avvio dell'istanza. La memoria condivisa è divisa in più sottoaree. Di seguito è possibile trovare una descrizione dei più importanti.

Buffer condivisi

Il pool buffer condiviso è un'area di memoria Aurora PostgreSQL che contiene tutte le pagine che sono o sono state utilizzate dalle connessioni delle applicazioni. Una pagina è la versione di memoria di un blocco disco. Il buffer pool condiviso memorizza nella cache i blocchi di dati letti dal disco. Il pool riduce la necessità di rileggere i dati dal disco, rendendo il database più efficiente.

Ogni tabella e indice vengono memorizzati come una matrice di pagine di dimensioni fisse. Ogni blocco contiene più tuple, che corrispondono alle righe. Una tupla può essere memorizzata in qualsiasi pagina.

Il buffer pool condiviso ha memoria finita. Se una nuova richiesta richiede una pagina che non è in memoria, e non esiste più memoria, Aurora PostgreSQL sfratterà una pagina utilizzata meno frequentemente per soddisfare la richiesta. La politica di sfratto è implementata da un algoritmo di sweep dell'orologio.

Il parametro shared_buffers determina la quantità di memoria che il server dedica alla memorizzazione nella cache dei dati.

Buffer Write ahead log (WAL)

Un Buffer write-ahead log (WAL) conserva i dati delle transazioni che Aurora PostgreSQL successivamente scrive sullo storage persistente. Utilizzando il meccanismo WAL, Aurora PostgreSQL può effettuare le seguenti operazioni:

Quando un client modifica i dati, Aurora PostgreSQL scrive le modifiche nel buffer WAL. Quando il client emette un COMMIT, il processo di scrittura WAL scrive i dati delle transazioni nel file WAL.

Il parametro wal_level determina la quantità di informazioni scritte sul WAL.

Memoria locale in Aurora PostgreSQL

Ogni processo di back-end assegna memoria locale per l'elaborazione delle query.

Area di memoria di lavoro

L’area di memoria di lavoro contiene dati temporanei per query che eseguono ordinamenti e hash. Ad esempio, una query con clausola ORDER BY esegue un ordinamento. Le query utilizzano tabelle hash nei join e nelle aggregazioni hash.

Il parametro work_mem indica la quantità di memoria da utilizzare dalle operazioni di ordinamento interno e dalle tabelle hash prima di scrivere su file di disco temporanei. Il valore predefinito è 4 MB. È possibile eseguire più sessioni contemporaneamente e ogni sessione può eseguire operazioni di manutenzione in parallelo. Per questo motivo, la memoria di lavoro totale utilizzata può essere costituita da multipli dell’impostazione work_mem.

Area memoria di lavoro di manutenzione

L’area di memoria di lavoro di manutenzione memorizza nella cache i dati per le operazioni di manutenzione. Queste operazioni includono l'aspirazione, la creazione di un indice e l'aggiunta di chiavi esterne.

Il parametro maintenance_work_mem specifica la quantità massima di memoria da utilizzare nelle operazioni di manutenzione. Il valore predefinito è 64 MB. Una sessione di database può eseguire solo un'operazione di manutenzione alla volta.

Area buffer temporanea

L’area buffer temporanea memorizza nella cache le tabelle temporanee per ciascuna sessione del database.

Ogni sessione assegna buffer temporanei secondo necessità fino al limite specificato. Quando la sessione scade, il server cancella i buffer.

Il parametro temp_buffers imposta il numero massimo di buffer temporanei utilizzati da ogni sessione. Prima del primo utilizzo di tabelle temporanee all'interno di una sessione, è possibile modificare il valore temp_buffers.

Processi Aurora PostgreSQL

Aurora PostgreSQL utilizza più processi.

Processo postmaster

Il processo postmaster è il primo processo avviato quando si avvia Aurora PostgreSQL. Il processo postmaster ha le seguenti responsabilità principali:

Processi di back-end

Se il postmaster autentica una richiesta del cliente, il postmaster forcherà un nuovo processo di back-end, chiamato anche processo postgres. Un processo client si connette esattamente a un processo back-end. Il processo client e il processo di backend comunicano direttamente senza intervento da parte del processo postmaster.

Processi in background

Il processo postmaster forca diversi processi che eseguono diverse attività di back-end. Alcuni dei più importanti includono quanto segue: