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 VACUUM e ANALYZE. VACUUM ha le seguenti varianti: standard e full. Il vuoto standard funziona in parallelo con altre operazioni di database. VACUUM FULL richiede 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 I/O traffico, che può causare scarse prestazioni per altre sessioni attive.