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 RDS per PostgreSQL
Prima di ottimizzare il database RDS per 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 RDS per PostgreSQL. Per un utile diagramma architettonico, vedere il wikibook PostgreSQL
Argomenti
Eventi di attesa di RDS per PostgreSQL
Un evento di attesa indica che una sessione è in attesa di una risorsa. Ad esempio, l'evento di attesa Client:ClientRead si verifica quando RDS per PostgreSQL è in attesa di ricevere dati dal client. Le sessioni in genere attendono risorse come le seguenti.
-
Accesso a thread singolo a un buffer, ad esempio, quando una sessione sta tentando di modificare un buffer
-
Una riga attualmente bloccata da un'altra sessione
-
Un file di dati letto
-
Scrittura di un file log
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.
Di per sé, un singolo evento di attesa non indica 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 RDS per PostgreSQL
La memoria RDS per PostgreSQL è divisa in condivisa e locale.
Memoria condivisa in RDS per PostgreSQL
RDS per 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 RDS per 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, RDS per PostgreSQL espelle 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 RDS per PostgreSQL successivamente scrive sull'archiviazione persistente. Utilizzando il meccanismo WAL, RDS per PostgreSQL può effettuare le seguenti operazioni:
-
Recuperare i dati dopo un errore
-
Ridurre l'I/O del disco evitando scritture frequenti su disco
Quando un client modifica i dati, RDS per 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 RDS per 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 di RDS per PostgreSQL
RDS per PostgreSQL utilizza più processi.
Processo postmaster
Il processo postmaster è il primo processo eseguito quando si avvia RDS per PostgreSQL. Il processo postmaster ha le seguenti responsabilità principali:
-
Forcella e monitoraggio dei processi in background
-
Ricevere le richieste di autenticazione dai processi client e autenticarle prima di consentire al database di servire le richieste
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:
-
Scrittore WAL
RDS per PostgreSQL scrive i dati nel buffer WAL (write ahead logging) nei file di log. Il principio della registrazione write ahead è che il database non può scrivere modifiche ai file di dati fino a quando il database ha scritto i record di log che descrivono tali modifiche su disco. Il meccanismo WAL riduce l'I/O del disco e consente a RDS per PostgreSQL di utilizzare i log per recuperare il database dopo un errore.
-
Background writer
Questo processo scrive periodicamente pagine sporche (modificate) dai buffer di memoria ai file di dati. Una pagina diventa sporca quando un processo di back-end la modifica in memoria.
-
Il daemon dell'Autovacuum
Il daemon include i seguenti elementi:
-
Il lanciatore di autovacuum
-
I processi di autovacuum worker
Se abilitata, verifica la presenza di tabelle con un numero elevato di tuple inserite, aggiornate o eliminate. Il daemon ha le seguenti responsabilità:
-
Recuperare o riutilizzare lo spazio su disco occupato da righe aggiornate o eliminate
-
Aggiornare le statistiche utilizzate dal planner
-
Proteggere contro la perdita di dati precedenti a causa di un involucro dell'ID transazione
La funzione autovacuum automatizza l'esecuzione dei comandi
VACUUMeANALYZE.VACUUMha le seguenti varianti: standard e full. Il vuoto standard funziona in parallelo con altre operazioni di database.VACUUM FULLrichiede un blocco esclusivo sulla tabella su cui sta lavorando. Pertanto, non può essere eseguito in parallelo con le operazioni che accedono alla stessa tabella.VACUUMcrea una notevole quantità di traffico I/O, che può causare prestazioni scadenti per altre sessioni attive. -
