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à. # Prestazioni e dimensionamento per 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. **Topics** + [Dimensionamento delle istanze database Aurora PostgreSQL](#AuroraPostgreSQL.Managing.Performance.InstanceScaling) + [Numero massimo di connessioni a un'istanza database Aurora PostgreSQL](#AuroraPostgreSQL.Managing.MaxConnections) + [Limiti di storage temporaneo per Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage) + [Huge Pages per Aurora PostgreSQL](#AuroraPostgreSQL.Managing.HugePages) + [Test di Amazon Aurora PostgreSQL mediante query Fault Injection](AuroraPostgreSQL.Managing.FaultInjectionQueries.md) + [Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md) + [Specificare il disco RAM per stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md) + [Gestione dei file temporanei con PostgreSQL](PostgreSQL.ManagingTempFiles.md) ## 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](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling). 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](Concepts.DBInstanceClass.Types.md). 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](Aurora.Replication.md#Aurora.Replication.Replicas) e [Failover rapido con Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md). Per le specifiche dettagliate delle classi di istanza database supportate da Aurora PostgreSQL, consulta [Motori di database supportati per classi di istanza database](Concepts.DBInstanceClass.SupportAurora.md). ## 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](https://aws.amazon.com/blogs/database/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 utilizzando `psql` che genera messaggi di errore come il seguente: ``` psql: FATAL: remaining connection slots are reserved for non-replication superuser connections ``` + Se il valore `max_connections` supera 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](AuroraPostgreSQL.Reference.ParameterGroups.md) e [Creazione di un gruppo di parametri del cluster DB in Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md). **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 [Proxy Amazon RDS per Aurora](rds-proxy.md). Per informazioni dettagliate su come le istanze Aurora Serverless v2 gestiscono questo parametro, vedi [Numero massimo connessioni per Aurora Serverless v2](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). ## 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?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue). 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 [Archiviazione Amazon Aurora](Aurora.Overview.StorageReliability.md). È inoltre possibile aumentare l'archiviazione locale per gli oggetti temporanei utilizzando un tipo di istanza NVMe abilitato e oggetti temporanei abilitati per Aurora Optimized Reads-enabled. Per ulteriori informazioni, consulta [Prestazioni delle query migliorate per Aurora PostgreSQL con Letture ottimizzate per Aurora](AuroraPostgreSQL.optimized.reads.md). **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 [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md). | 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.r8g.48xlarge | 3072 | | db.r8g.24xlarge | 1536 | | db.r8g.16xlarge | 998 | | db.r8g.12xlarge | 749 | | db.r8g.8xlarge | 499 | | db.r8g.4xlarge | 250 | | db.r8g.2xlarge | 125 | | db.r8g.xlarge | 63 | | db.r8g.large | 31 | | 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.r7i.48xlarge | 3072 | | db.r7i.24xlarge | 1500 | | db.r7i.16xlarge | 1008 | | db.r7i.12xlarge | 748 | | db.r7i.8xlarge | 504 | | db.r7i.4xlarge | 249 | | db.r7i.2xlarge | 124 | | db.r7i.xlarge | 62 | | db.r7i.large | 31 | | 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** NVMe i tipi di istanza abilitati possono aumentare lo spazio temporaneo disponibile fino alla NVMe dimensione totale. Per ulteriori informazioni, consulta [Prestazioni delle query migliorate per Aurora PostgreSQL con Letture ottimizzate per Aurora](AuroraPostgreSQL.optimized.reads.md). È possibile monitorare lo spazio di archiviazione temporaneo disponibile per un'istanza DB con la `FreeLocalStorage` CloudWatch metrica --> descritta in. [CloudWatch Parametri Amazon per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md) (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\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) o [maintenance \$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) PostgreSQL. ## 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. Nelle istanze database Aurora PostgreSQL che non supportano la funzionalità di memoria per pagine di grandi dimensioni, l’utilizzo della memoria di processi specifici potrebbe aumentare senza le corrispondenti modifiche del carico di lavoro. Il sistema alloca segmenti di memoria condivisa come la cache del buffer durante l’avvio del server. Quando non sono disponibili pagine di memoria di grandi dimensioni, il sistema non addebita queste allocazioni al processo postmaster. Al contrario, include la memoria nel processo che ha effettuato per primo l’accesso a ogni pagina da 4 KB nel segmento di memoria condivisa. **Nota** Le connessioni attive condividono la memoria allocata in base alle esigenze, indipendentemente dal modo in cui l’utilizzo della memoria condivisa viene monitorato tra i processi. # Test di Amazon Aurora PostgreSQL mediante query Fault Injection Puoi testare la tolleranza ai guasti del tuo cluster di database Aurora PostgreSQL utilizzando query fault injection. Le query di errore di iniezione vengono emesse come comandi SQL per un'istanza Amazon Aurora. Le query fault injection consentono di arrestare l'istanza in maniera anomala per poter testare il failover e il ripristino. È anche possibile simulare errore della replica di Aurora Replica, errore del disco e congestione del disco. Le query di fault injection sono supportate da tutte le versioni di Aurora PostgreSQL disponibili, come riportato di seguito. + Aurora PostgreSQL versioni 12, 13, 14 e successive + Aurora PostgreSQL versione 11.7 e versioni successive + Aurora PostgreSQL versione 10.11 e versioni successive **Topics** + [Test dell'arresto anomalo di un'istanza](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Test di un errore di replica Aurora](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Test di un errore del disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Test di una congestione del disco](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Quando una query fault injection specifica un arresto anomalo, impone un arresto anomalo dell'istanza database di Aurora PostgreSQL. Le altre query fault injection generano simulazioni di eventi di errore, ma non causano l'evento. Quando invii una query fault injection, specifichi anche la durata della simulazione dell'evento di errore. Puoi inviare una query fault injection a una delle istanze di replica Aurora eseguendo la connessione all'endpoint per la replica Aurora. Per ulteriori informazioni, consulta [Connessioni degli endpoint Amazon Aurora](Aurora.Overview.Endpoints.md). ## Test dell'arresto anomalo di un'istanza Puoi forzare un arresto anomalo di un'istanza Aurora PostgreSQL utilizzando la funzione query fault injection `aurora_inject_crash()`. Per questa query fault injection, non si verifica alcun failover. Se desideri testare un failover, puoi scegliere l'azione dell'istanza di **failover** per il tuo cluster DB nella console RDS o utilizzare il [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI comando o l'operazione API [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS. **Sintassi** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Opzioni Questa query fault injection accetta uno dei seguenti tipi di arresto anomalo. Il tipo di arresto anomalo non rileva la distinzione tra maiuscole e minuscole: *'instance'* Viene simulato un arresto anomalo del database compatibile con PostgreSQL per l'istanza Amazon Aurora. *'dispatcher'.* Viene simulato un arresto anomalo del dispatcher sull'istanza primaria per il cluster di database Aurora. Il *dispatcher* scrive gli aggiornamenti sul volume del cluster per un cluster di database Amazon Aurora. *'node'* Viene simulato un arresto anomalo del database compatibile con PostgreSQL e del dispatcher per l'istanza Amazon Aurora. ## Test di un errore di replica Aurora Puoi simulare l'errore di una replica Aurora mediante la funzione query fault injection `aurora_inject_replica_failure()`. Un errore di replica Aurora blocca la replica nella replica Aurora o in tutte le repliche Aurora nel cluster di database in base alla percentuale specificata per l'intervallo di tempo specificato. Al termine di tale periodo, le repliche Aurora interessate sono automaticamente sincronizzate con l'istanza primaria. **Sintassi** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Opzioni Questa query fault injection accetta i seguenti parametri: *percentage\$1of\$1failure* La percentuale di repliche da bloccare durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, non viene bloccata alcuna replica. Se specifichi 100, vengono bloccate tutte le repliche. *time\$1interval* L'intervallo di tempo per simulare l'errore di replica Aurora. L’intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi. Fai attenzione quando specifichi l'intervallo di tempo per l'evento di errore della replica Aurora. Se specifichi un intervallo troppo lungo e l'istanza di scrittura scrive una grande quantità di dati durante l'evento di errore, il cluster database Aurora potrebbe ritenere che si è verificato un arresto anomalo della replica Aurora e quindi sostituirla. *replica\$1name* La replica Aurora in cui inserire la simulazione dell'errore. Specifica il nome della replica Aurora per simulare un errore di una singola replica Aurora. Specifica una stringa vuota per simulare errori per tutte le repliche Aurora nel cluster database. Per identificare i nomi delle repliche, vedere la colonna `server_id` della funzione `aurora_replica_status()`. Ad esempio: ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Test di un errore del disco Puoi simulare un errore del disco per un cluster database Aurora PostgreSQL mediante la funzione query fault injection `aurora_inject_disk_failure()`. Durante la simulazione di un errore del disco, il cluster di database Aurora PostgreSQL contrassegna in modo aleatorio i segmenti del disco come difettosi. Le richieste a tali segmenti sono bloccate per la durata della simulazione. **Sintassi** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Opzioni Questa query fault injection accetta i seguenti parametri: *percentage\$1of\$1failure* La percentuale del disco da contrassegnare come difettosa durante l'evento di errore. Può essere un valore tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come difettosa. Se specifichi 100, tutto il disco è contrassegnato come difettoso. *index* Un blocco di dati logico specifico nel quale simulare l'evento di errore. Se viene superato l'intervallo di blocchi logici o di dati dei nodi di storage disponibili, viene generato un errore che indica il valore di indice massimo che puoi specificare. Per evitare questo errore, consulta [Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica se l'errore di inserimento è in un blocco logico o in un nodo di storage. Se si specifica true, significa che gli errori di inserimento sono in un blocco logico. Se si specifica false, significa che gli errori di inserimento sono in un nodo di storage. *time\$1interval* L’intervallo di tempo per simulare l’errore del disco. L’intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi. ## Test di una congestione del disco È possibile simulare una congestione del disco per un cluster di database Aurora PostgreSQL mediante la funzione di query di iniezione di guasti `aurora_inject_disk_congestion()`. Durante la simulazione della congestione del disco, il cluster di database Aurora PostgreSQL contrassegna in modo aleatorio i segmenti del disco come congestionati. Le richieste a tali segmenti vengono ritardate di un periodo di tempo compreso tra il ritardo minimo e quello massimo specificati per la durata della simulazione. **Sintassi** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Opzioni Questa query fault injection accetta i seguenti parametri: *percentage\$1of\$1failure* La percentuale del disco da contrassegnare come congestionata durante l'evento di errore. Questo è un doppio valore compreso tra 0 e 100. Se specifichi 0, nessuna parte del disco è contrassegnata come congestionata. Se specifichi 100, tutto il disco è contrassegnato come congestionato. *index* Un blocco di dati logico o nodo storage specifico nel quale simulare l'evento di errore. Se viene superato l'intervallo di blocchi logici o di dati dei nodi di storage disponibili, viene generato un errore che indica il valore di indice massimo che puoi specificare. Per evitare questo errore, consulta [Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indica se l'errore di inserimento è in un blocco logico o in un nodo di storage. Se si specifica true, significa che gli errori di inserimento sono in un blocco logico. Se si specifica false, significa che gli errori di inserimento sono in un nodo di storage. *time\$1interval* L’intervallo di tempo per simulare la congestione del disco. L’intervallo è in secondi. Ad esempio, se il valore è 20, la simulazione viene eseguita per 20 secondi. *minimum, maximum* Il valore minimo e massimo del ritardo di congestione in millisecondi. I valori validi sono compresi tra 0,0 e 100,0 millisecondi. I segmenti del disco contrassegnati come congestionati vengono ritardati per un periodo di tempo aleatorio compreso nell'intervallo del valore minimo e massimo per la durata della simulazione. Il valore massimo deve essere maggiore del valore minimo. # Visualizzazione dello stato del volume per un cluster di database Aurora PostgreSQL In Amazon Aurora, un volume di cluster di database è costituito da una raccolta di blocchi logici. Ognuno di questi rappresenta 10 gigabyte di storage allocato. Questi blocchi sono denominati *gruppi di protezione*. I dati in ogni gruppo di protezione sono replicati su sei dispositivi di storage fisico denominati *nodi di storage*. Questi nodi di storage sono allocati su tre zone di disponibilità (AZs) nella regione in cui risiede il cluster DB. Ogni nodo di storage contiene a sua volta uno o più blocchi di dati logici per il volume di cluster di database. Per ulteriori informazioni sui gruppi di protezione e sui nodi di archiviazione, vedere [Introduzione al motore di storage Aurora](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) sul blog del AWS database. Per ulteriori informazioni sui volumi del cluster Aurora, consulta [Archiviazione Amazon Aurora](Aurora.Overview.StorageReliability.md). Utilizza la funzione `aurora_show_volume_status()` per restituire le seguenti variabili di stato del server: + `Disks` — Il numero totale di blocchi logici di dati per il volume del cluster di database. + `Nodes` **—** Il numero totale di nodi di storage per il volume del cluster di database. Puoi utilizzare la funzione `aurora_show_volume_status()` per evitare errori durante l'utilizzo la funzione fault injection `aurora_inject_disk_failure()`. La funzione fault injection `aurora_inject_disk_failure()` simula l'errore di un intero nodo di storage o di un singolo blocco logico di dati all'interno di un nodo di storage. Nella funzione, si specifica il valore di indice di un blocco logico di dati o nodo di storage specifico. Tuttavia, l'istruzione restituisce un errore se si specifica un valore di indice superiore al numero di blocchi di dati logici o nodi di storage utilizzati dal volume del cluster di database. Per ulteriori informazioni sulle query fault injection, consulta [Test di Amazon Aurora PostgreSQL mediante query Fault Injection](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **Nota** La funzione `aurora_show_volume_status()` è disponibile per Aurora PostgreSQL versione 10.11. Per ulteriori informazioni sulle versioni di Aurora PostgreSQL, consulta [versioni di Amazon Aurora PostgreSQL e versioni del motore](AuroraPostgreSQL.Updates.20180305.md). **Sintassi** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Esempio** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # Specificare il disco RAM per stats\$1temp\$1directory Puoi utilizzare il parametro di Aurora PostgreSQL, `rds.pg_stat_ramdisk_size`, per specificare la memoria di sistema allocata a un disco RAM per l'archiviazione di `stats_temp_directory` PostgreSQL. Il parametro del disco RAM è disponibile in Aurora PostgreSQL 14 e versioni precedenti. Per alcuni carichi di lavoro, l'impostazione di questo parametro può migliorare le prestazioni e ridurre i requisiti IO. Per ulteriori informazioni sul parametro `stats_temp_directory`, consulta [Run-time Statistics](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) nella documentazione di PostgreSQL. A partire dalla versione 15 di PostgreSQL, la community PostgreSQL ha iniziato a utilizzare la memoria condivisa dinamica. Quindi, non è necessario impostare `stats_temp_directory`. Per abilitare un disco RAM per `stats_temp_directory`, imposta il parametro `rds.pg_stat_ramdisk_size` su un valore diverso da zero nel gruppo di parametri del cluster di database utilizzato dal tuo cluster di database. Questo parametro utilizza MB, quindi è necessario specificare un valore intero. Espressioni, formule e funzioni non sono valide per il parametro `rds.pg_stat_ramdisk_size`. Assicurati di riavviare il cluster di database in modo che la modifica abbia effetto. Per informazioni sull'estensione dei parametri consulta [Gruppi di parametri per Amazon Aurora](USER_WorkingWithParamGroups.md). Per ulteriori informazioni sul riavvio del cluster database, consulta [Riavvio di un cluster Amazon Aurora DB o di un'istanza Amazon Aurora DB](USER_RebootCluster.md). Ad esempio, il AWS CLI comando seguente imposta il parametro del disco RAM su 256 MB. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Dopo il riavvio di cluster di database, esegui il seguente comando per visualizzare lo stato di `stats_temp_directory`: ``` postgres=> SHOW stats_temp_directory; ``` Il comando deve restituire i seguenti valori: ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Gestione dei file temporanei con PostgreSQL In PostgreSQL, una query complessa può eseguire più operazioni di ordinamento o hash contemporaneamente, ciascuna delle quali utilizza la memoria dell’istanza per archiviare i risultati fino al valore specificato nel parametro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Quando la memoria dell'istanza non è sufficiente, vengono creati file temporanei per archiviare i risultati. Questi vengono scritti su disco per completare l'esecuzione della query. Successivamente, questi file vengono rimossi automaticamente al completamento della query. In In Aurora PostgreSQL, questi file condividono l'archiviazione locale con altri file di log. Puoi monitorare lo spazio di archiviazione locale del cluster Aurora PostgreSQL DB osservando la metrica Amazon per. CloudWatch `FreeLocalStorage` Per ulteriori informazioni, consulta [Risoluzione dei problemi relativi all'archiviazione locale](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/). Consigliamo di utilizzare cluster di lettura ottimizzata per Aurora per i carichi di lavoro che comportano più query simultanee che aumentano l’utilizzo di file temporanei. Questi cluster di utilizzano lo storage locale a livello di blocco basato su unità SSD (Solid State DriveNVMe) basate su Non-Volatile Memory Express () per collocare i file temporanei. Per ulteriori informazioni, consulta [Prestazioni delle query migliorate per Aurora PostgreSQL con Letture ottimizzate per Aurora](AuroraPostgreSQL.optimized.reads.md). È possibile utilizzare i seguenti parametri e funzioni per gestire i file temporanei nell'istanza. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)**: questo parametro annulla qualsiasi query che superi la dimensione definita in KB dal parametro temp\$1files. Questo limite impedisce a qualsiasi query di essere eseguita all'infinito e di consumare spazio su disco con file temporanei. È possibile stimare il valore utilizzando i risultati del parametro `log_temp_files`. È consigliabile esaminare il comportamento del carico di lavoro e impostare il limite in base alla stima. Gli esempi seguenti mostrano come viene annullata una query quando supera il limite. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)**: questo parametro invia messaggi a postgresql.log quando i file temporanei di una sessione vengono rimossi. Questo parametro produce log dopo che una query è stata completata correttamente. Pertanto, potrebbe non essere utile nella risoluzione dei problemi delle query attive e con tempi di esecuzione lunghi. L'esempio seguente mostra che quando la query viene completata correttamente, le voci vengono registrate nel file postgresql.log mentre i file temporanei vengono eliminati. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)**: questa funzione disponibile in RDS per PostgreSQL 13 e versioni successive fornisce visibilità sull'attuale utilizzo dei file temporanei. La query completata non viene visualizzata nei risultati della funzione. Nell'esempio seguente, è possibile visualizzare i risultati di questa funzione. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` Il nome del file include l'ID di elaborazione (PID) della sessione che ha generato il file temporaneo. Una query più avanzata, come nell'esempio seguente, esegue la somma dei file temporanei per ogni PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`**: se attivi il parametro pg\$1stat\$1statements, puoi visualizzare l'utilizzo medio dei file temporanei per chiamata. È possibile identificare il valore query\$1id della query e utilizzarlo per esaminare l'utilizzo dei file temporanei, come illustrato nell'esempio seguente. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`**: nel pannello di controllo di Approfondimenti sulle prestazioni, puoi visualizzare l'utilizzo dei file temporanei attivando le metriche **temp\$1bytes** e **temp\$1files**. Puoi quindi vedere la media di entrambe queste metriche e verificare se corrispondono al carico di lavoro delle query. La visualizzazione all'interno di Approfondimenti sulle prestazioni non evidenzia in modo specifico le query che generano file temporanei. Tuttavia, combinando le informazioni di Approfondimenti sulle prestazioni con la query mostrata per il parametro `pg_ls_tmpdir`, è possibile definire, analizzare e risolvere eventuali problemi a livello di modifiche del carico di lavoro delle query. Per ulteriori informazioni su come analizzare metriche e query con Approfondimenti sulle prestazioni, consulta [Analisi delle metriche utilizzando il pannello di controllo Performance Insights](USER_PerfInsights.UsingDashboard.md). Per un esempio di visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni, consulta [Visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni](PostgreSQL.ManagingTempFiles.Example.md). # Visualizzazione dell’utilizzo dei file temporanei con Approfondimenti sulle prestazioni È possibile utilizzare Approfondimenti sulle prestazioni per visualizzare l’utilizzo dei file temporanei attivando le metriche **temp\$1bytes** e **temp\$1files**. La visualizzazione in Approfondimenti sulle prestazioni non mostra le query specifiche che generano i file temporanei. Tuttavia, combinando Approfondimenti sulle prestazioni con la query mostrata per `pg_ls_tmpdir`, è possibile risolvere i problemi, analizzare e determinare le modifiche nel carico di lavoro delle query. 1. Nel pannello di controllo di Approfondimenti sulle prestazioni, scegli **Gestisci parametri**. 1. Seleziona **Metriche del database** e quindi seleziona le metriche **temp\$1bytes** e **temp\$1files** come illustrato nell'immagine seguente. ![\[I parametri sono visualizzati nel grafico.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. Nella scheda **SQL principale**, scegli l'icona **Preferenze**. 1. Nella finestra **Preferenze**, attiva le seguenti statistiche per visualizzarle nella scheda **SQL principale** e scegli **Continua**. + Scritture temporanee al secondo + Letture temporanee al secondo + Scritture temporanee in blocco a chiamata + Letture temporanee in blocco a chiamata 1. Il file temporaneo viene suddiviso quando viene combinato con la query visualizzata per `pg_ls_tmpdir`, come illustrato nell'esempio seguente. ![\[Query che visualizza l'utilizzo dei file temporanei.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Gli eventi `IO:BufFileRead` e `IO:BufFileWrite` si verificano quando le query principali del carico di lavoro creano spesso file temporanei. Puoi utilizzare Approfondimenti sulle prestazioni per identificare le query di livello superiore in attesa di `IO:BufFileRead` e `IO:BufFileWrite` esaminando la metrica Sessioni attive medie (AAS) nelle sezioni Caricamento del database e SQL principale. ![\[IO: BufFileRead e IO: BufFileWrite nel grafico.\]](http://docs.aws.amazon.com/it_it/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Per ulteriori informazioni su come analizzare metriche principali ed eventi di attesa con Approfondimenti sulle prestazioni, consulta [Panoramica della scheda Prime istruzioni SQL](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Devi individuare e ottimizzare le query che causano un aumento dell'utilizzo dei file temporanei e dei relativi eventi di attesa. Per ulteriori informazioni su questi eventi di attesa e sulla correzione, vedere [IO: BufFileRead and IO: BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **Nota** Il parametro [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) controlla quando l'operazione di ordinamento esaurisce la memoria; i risultati vengono scritti in file temporanei. Si consiglia di non modificare l'impostazione di questo parametro specificando un valore superiore al valore predefinito perché ciò causerebbe un maggiore utilizzo della memoria da parte di ciascuna sessione del database. Inoltre, una sessione che esegue unioni e ordinamenti complessi può eseguire operazioni parallele in cui ogni operazione consuma memoria. Come best practice, in presenza di un report di grandi dimensioni con più unioni e ordinamenti, imposta questo parametro a livello di sessione utilizzando il comando `SET work_mem`. La modifica verrà quindi applicata solo alla sessione corrente e non comporterà la modifica del valore a livello globale.