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à.
Gestione di Amazon Aurora PostgreSQL
La sezione seguente descrive come gestire le prestazioni e il dimensionamento per un cluster di database di Amazon Aurora PostgreSQL. Include anche informazioni su altre attività di manutenzione.
Argomenti
- Dimensionamento delle istanze database Aurora PostgreSQL
- Numero massimo di connessioni a un'istanza database Aurora PostgreSQL
- Limiti di storage temporaneo per Aurora PostgreSQL
- Huge Pages per Aurora PostgreSQL
- Test di Amazon Aurora PostgreSQL mediante query Fault Injection
- Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL
- Specificare il disco RAM per stats_temp_directory
- Gestione dei file temporanei con PostgreSQL
Dimensionamento delle istanze database Aurora PostgreSQL
È possibile dimensionare le istanze database Aurora PostgreSQL in due diversi modi, ovvero tramite il dimensionamento delle istanze e il dimensionamento della lettura. Per ulteriori informazioni sul dimensionamento della lettura, consulta Dimensionamento della lettura.
Puoi dimensionare il cluster di database Aurora PostgreSQL in base alle necessità, modificando la classe di istanza database per ogni istanza database nel cluster di database. Aurora PostgreSQL supporta diverse classi di istanza database ottimizzate per Aurora. Non utilizzare classi di istanza db.t2 o db.t3 per cluster Aurora più grandi di dimensioni maggiori di 40 terabyte (TB).
Nota
Consigliamo di utilizzare le classi di istanza database T solo per i server di sviluppo e test o altri server non di produzione. Per ulteriori informazioni sulle classi di istanza T, consulta Tipi di classi di istanza database.
Il dimensionamento non è immediato. Potrebbero essere necessari 15 minuti o più per completare la modifica a una classe di istanza database diversa. Se si utilizza questo approccio per modificare la classe di istanza database, la modifica viene applicata durante la prossima finestra di manutenzione pianificata (anziché immediatamente) per evitare di influenzare gli utenti.
In alternativa alla modifica diretta della classe di istanza database, è possibile ridurre al minimo i tempi di inattività utilizzando le funzionalità ad alta disponibilità di Amazon Aurora. Innanzitutto, aggiungi una replica Aurora al cluster. Quando crei la replica, scegli la dimensione della classe di istanza database da utilizzare per il cluster. Quando la replica Aurora è sincronizzata con il cluster, viene quindi eseguito il failover sulla replica appena aggiunta. Per ulteriori informazioni, consultare Repliche di Aurora e Failover rapido con Amazon Aurora PostgreSQL.
Per le specifiche dettagliate delle classi di istanza database supportate da Aurora PostgreSQL, consulta Motori DB supportati per classi di istanza database.
Numero massimo di connessioni a un'istanza database Aurora PostgreSQL
Un cluster di database Aurora PostgreSQL alloca le risorse in base alla classe dell'istanza database e alla memoria disponibile. Ogni connessione al cluster di database consuma quantità incrementali di queste risorse, come memoria e CPU. La memoria consumata per connessione varia in base al tipo di query, al conteggio e all'utilizzo delle tabelle temporanee. Anche una connessione inattiva consuma memoria e CPU. Questo perché quando le query vengono eseguite su una connessione, viene allocata più memoria per ogni query che non viene rilasciata completamente, anche quando l'elaborazione si arresta. Pertanto, ti consigliamo di assicurarti che le tue applicazioni non utilizzino connessioni inattive: ognuna di queste spreca risorse e influisce negativamente sulle prestazioni. Per ulteriori informazioni, consulta Resources consumed by idle PostgreSQL connections
Il numero massimo di connessioni consentite a un'istanza database di Aurora PostgreSQL è determinato dal valore del parametro max_connections specificato nel gruppo di parametri per quell'istanza database. L'impostazione ideale per il max_connections parametro è quella che supporta tutte le connessioni client necessarie all'applicazione, senza un eccesso di connessioni inutilizzate, più almeno altre 3 connessioni per supportare AWS l'automazione. Prima di modificare l'impostazione del parametro max_connections, è opportuno considerare quanto segue:
-
Se il valore
max_connectionsè troppo basso, l'istanza database di Aurora PostgreSQL potrebbe non avere connessioni sufficienti quando i client tentano di connettersi. Se ciò accade, tenta di connettersi utilizzandopsqlche genera messaggi di errore come il seguente:psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
Se il valore
max_connectionssupera il numero di connessioni effettivamente necessarie, le connessioni inutilizzate possono causare un peggioramento delle prestazioni.
Il valore predefinito di max_connections è derivato dalla seguente funzione Aurora PostgreSQL LEAST:
LEAST({DBInstanceClassMemory/9531392},5000).
Se desideri modificare il valore di max_connections, devi creare un gruppo di parametri cluster di database personalizzato e modificare il valore. Dopo aver applicato il gruppo di parametri database personalizzato al cluster, assicurati di riavviare l'istanza primaria in modo che il nuovo valore diventi effettivo. Per ulteriori informazioni, consultare Amazon Aurora PostgreSQL parametri e Creazione di un gruppo di parametri del cluster database.
Suggerimento
Se le applicazioni aprono e chiudono frequentemente connessioni o mantengono un numero elevato di connessioni di lunga durata aperte, ti consigliamo di utilizzare Server proxy per Amazon RDS. Proxy RDS è un proxy di database completamente gestito e ad alta disponibilità che utilizza il pooling di connessioni per condividere connessioni di database in modo sicuro ed efficiente. Per ulteriori informazioni sul Proxy RDS, consulta Utilizzo di Server proxy per Amazon RDS per Aurora.
Per informazioni dettagliate su come le istanze Aurora Serverless v2 gestiscono questo parametro, vedi Numero massimo connessioni per Aurora Serverless v2.
Limiti di storage temporaneo per Aurora PostgreSQL
Aurora PostgreSQL memorizza tabelle e indici nel sottosistema di archiviazione Aurora. Aurora PostgreSQL utilizza l'archiviazione temporanea separata per i file temporanei non persistenti. Sono inclusi i file utilizzati per scopi quali l'ordinamento di set di dati di grandi dimensioni durante l'elaborazione delle query o per le operazioni di creazione dell'indice. Per ulteriori informazioni, consulta l'articolo Come posso risolvere i problemi di archiviazione locale nelle istanze compatibili con Aurora PostgreSQL?
Questi volumi di archiviazione locale sono supportati da Amazon Elastic Block Store e possono essere estesi utilizzando una classe di istanza database più grande. Per ulteriori informazioni sullo storage, consultare Storage e affidabilità di Amazon Aurora. È inoltre possibile aumentare l'archiviazione locale per gli oggetti temporanei utilizzando un tipo di istanza abilitato per NVMe e oggetti temporanei abilitati per Aurora Optimized Reads. Per ulteriori informazioni, consulta Prestazioni delle query migliorate per Aurora PostgreSQL con Letture ottimizzate per Aurora.
Nota
Durante il dimensionamento delle istanze database, ad esempio da db.r5.2xlarge a db.r5.4xlarge, potrebbero essere visualizzati eventi storage-optimization.
La tabella seguente mostra la quantità massima di storage temporaneo disponibile per ogni classe di istanza database Aurora PostgreSQL. Per ulteriori informazioni sul supporto della classe di istanza database per Aurora, consultare Aurora Classi di istanze database.
| DB instance class (Classe istanza database) | Storage temporaneo massimo disponibile (GiB) |
|---|---|
| db.x2g.16xlarge | 1829 |
| db.x2g.12xlarge | 1606 |
| db.x2g.8xlarge | 1071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r7g.16xlarge | 1008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r6g.16xlarge | 1008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1829 |
| db.r6i.24xlarge | 1500 |
| db.r6i.16xlarge | 1008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1500 |
| db.r5.16xlarge | 1008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16,5 |
| db.t4g.medium | 8,13 |
| db.t3.large | 16 |
| db.t3.medium | 7,5 |
Nota
I tipi di istanze abilitati per NVMe possono aumentare lo spazio temporaneo disponibile fino alla dimensione totale di NVMe. Per ulteriori informazioni, consulta Prestazioni delle query migliorate per Aurora PostgreSQL con Letture ottimizzate per Aurora.
È possibile monitorare lo storage temporaneo disponibile per un'istanza DB con la FreeLocalStorage CloudWatch metrica --> descritta in. CloudWatch Parametri Amazon per Amazon Aurora (Non valido per Aurora Serverless v2)
Per alcuni carichi di lavoro, è possibile ridurre la quantità di storage temporaneo allocando più memoria ai processi che stanno perfezionando l'operazione. Per aumentare la memoria disponibile per un'operazione, aumentando i valori dei parametri work_mem
Huge Pages per Aurora PostgreSQL
Le pagine di grandi dimensioni sono una caratteristica di gestione della memoria che riduce il sovraccarico quando un'istanza database lavora con grandi blocchi di memoria contigui, come quelli utilizzati dai buffer condivisi. Questa caratteristica di PostgreSQL è supportata da tutte le versioni Aurora PostgreSQL attualmente disponibili.
Il parametro Huge_pages è attivato per impostazione predefinita per tutte le classi di istanza database diverse dalle classi di istanza t3.medium, db.t3.large, db.t4g.medium, db.t4g.large Non è possibile modificare il valore del parametro huge_pages o disattivare questa funzionalità nelle classi di istanza supportate di Aurora PostgreSQL.
