;
```
Se la disabilitazione del parallelismo produce risultati migliori o più coerenti, prendere in considerazione la possibilità di disabilitarlo per query specifiche a livello di sessione utilizzando i comandi SET. Per un impatto più ampio, è possibile voler disabilitare il parallelismo a livello di istanza regolando i parametri pertinenti nel cluster o nel gruppo di parametri dell’istanza. Per ulteriori informazioni, consulta [Amazon Aurora PostgreSQL parametri](AuroraPostgreSQL.Reference.ParameterGroups.md).
### Monitorare l’utilizzo delle query parallele
Utilizzare le seguenti query per ottenere visibilità sull’attività e sulla capacità delle query parallele:
Controllare i processi worker paralleli attivi:
```
SELECT
COUNT(*)
FROM
pg_stat_activity
WHERE
backend_type = 'parallel worker';
```
Questa query mostra il numero di processi worker paralleli attivi. Un valore elevato può indicare che `max\$1parallel\$1workers` è configurato con un valore elevato e potrebbe essere opportuno ridurlo.
Controllare le query parallele simultanee:
```
SELECT
COUNT(DISTINCT leader_pid)
FROM
pg_stat_activity
WHERE
leader_pid IS NOT NULL;
```
Questa query restituisce il numero di processi leader distinti che hanno avviato query parallele. Un numero elevato indica che più sessioni eseguono query parallele contemporaneamente, il che può aumentare la richiesta di CPU e memoria.
### Esaminare e modificare le impostazioni delle interrogazioni parallele
Controllare i seguenti parametri per assicurarsi che siano in linea con il carico di lavoro:
+ `max_parallel_workers`: numero totale di worker paralleli in tutte le sessioni.
+ `max_parallel_workers_per_gather`: numero massimo di worker per query.
Per i carichi di lavoro OLAP, l’aumento di questi valori può migliorare le prestazioni. Per i carichi di lavoro OLTP, in genere sono preferiti valori inferiori.
```
SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
```
### Ottimizzare l’allocazione delle risorse
Monitora l'utilizzo della CPU e valuta la possibilità di regolare il numero di v CPUs se è costantemente elevato e se l'applicazione trae vantaggio dalle query parallele. Assicurarsi che sia disponibile una memoria adeguata per le operazioni parallele.
+ Utilizzare le metriche di Approfondimenti sulle prestazioni per determinare se il sistema è legato alla CPU.
+ Ogni worker parallelo utilizza il proprio `work_mem`. Assicurarsi che l’utilizzo totale della memoria rientri nei limiti delle istanze.
Le query parallele possono consumare molte più risorse rispetto alle query non parallele, poiché ogni processo worker è un processo completamente separato che ha all’incirca lo stesso impatto sul sistema di una sessione utente aggiuntiva. Questo deve essere tenuto in considerazione quando si sceglie un valore per questa impostazione, nonché quando si configurano altre impostazioni che controllano l’utilizzo delle risorse come `work_mem`. Per ulteriori informazioni, consultare la [documentazione di PostgreSQL](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). I limiti delle risorse come `work_mem` vengono applicati individualmente a ciascun worker, il che significa che l’utilizzo totale può essere molto più elevato in tutti i processi rispetto a quanto sarebbe normalmente per ogni singolo processo.
Prendi in considerazione l'aumento di v CPUs o l'ottimizzazione dei parametri di memoria se il carico di lavoro è fortemente parallelizzato.
### Esaminare la gestione delle connessioni
In caso di esaurimento delle connessioni, esaminare le strategie di pooling delle connessioni dell’applicazione. Prendere in considerazione l’implementazione del pooling delle connessioni a livello di applicazione, se non è già in uso.
### Esaminare e ottimizzare le operazioni di manutenzione
Coordinare la creazione degli indici e le altre attività di manutenzione per prevenire il conflitto di risorse. Prendere in considerazione la possibilità di pianificare queste operazioni durante le ore non di picco. Evitare di pianificare una manutenzione intensa (ad esempio, build di indici paralleli) durante i periodi di elevato carico di query da parte degli utenti. Queste operazioni possono consumare worker paralleli e influire sulle prestazioni delle query regolari.
### Utilizzare Query Plan Management (QPM)
In Aurora PostgreSQL, la funzionalità Query Plan Management (QPM) è progettata per garantire l’adattabilità e la stabilità del piano indipendentemente dalle modifiche apportate all’ambiente di database che potrebbero causare la regressione del piano di query. Per maggiori informazioni, consulta [Panoramica della gestione del piano di query per Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md). QPM fornisce un certo controllo sull’ottimizzatore. Esaminare i piani approvati in QPM per assicurarsi che siano in linea con le attuali impostazioni di parallelismo. Aggiornare o rimuovere i piani obsoleti che potrebbero forzare un’esecuzione parallela non ottimale.
È anche possibile correggere i piani utilizzando pg\$1hint\$1plan. Per ulteriori informazioni, consulta [Correzione dei piani mediante pg\$1hint\$1plan](AuroraPostgreSQL.Optimize.Maintenance.md#AuroraPostgreSQL.Optimize.Maintenance.pg_hint_plan). È possibile utilizzare l’hint denominato `Parallel` per imporre l’esecuzione parallela. Per maggiori informazioni, consulta la pagina relativa agli [hint per i piani paralleli](https://github.com/ossc-db/pg_hint_plan/blob/master/docs/hint_table.md#hints-for-parallel-plans).
# IPC: ProcArrayGroupUpdate
L'`IPC:ProcArrayGroupUpdate`evento si verifica quando una sessione è in attesa che il capogruppo aggiorni lo stato della transazione al termine dell'operazione. Sebbene PostgreSQL generalmente associ eventi di attesa di tipo IPC a operazioni di query parallele, questo particolare evento di attesa non è specifico delle query parallele.
**Topics**
+ [Versioni del motore supportate](#apg-rpg-ipcprocarraygroup.supported)
+ [Contesto](#apg-rpg-ipcprocarraygroup.context)
+ [Probabili cause di aumento delle attese](#apg-rpg-ipcprocarraygroup.causes)
+ [Azioni](#apg-rpg-ipcprocarraygroup.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
**Comprendere l'array di processi** — L'array process (proc) è una struttura di memoria condivisa in PostgreSQL. Contiene informazioni su tutti i processi in esecuzione, inclusi i dettagli delle transazioni. Durante il completamento della transazione (`COMMIT`o`ROLLBACK`), ProcArray deve essere aggiornato per riflettere la modifica e cancellare il TransactionID dall'array. La sessione che tenta di completare la transazione deve acquisire un blocco esclusivo su. ProcArray Ciò impedisce ad altri processi di ottenere blocchi condivisi o esclusivi su di esso.
**Meccanismo di aggiornamento di gruppo**: durante l'esecuzione di un COMMIT o ROLLBACK, se un processo di backend non riesce a ottenerne uno ProcArrayLock in modalità esclusiva, aggiorna un campo speciale chiamato. ProcArrayGroupMember Ciò aggiunge la transazione all'elenco delle sessioni che intendono terminare. Questo processo di backend quindi dorme e il tempo in cui dorme viene utilizzato come evento di attesa. ProcArrayGroupUpdate Il primo processo ProcArray con procArrayGroup Member, denominato processo leader, acquisisce la modalità esclusiva. ProcArrayLock Quindi cancella l'elenco dei processi in attesa della cancellazione del gruppo TransactionID. Una volta completata questa operazione, il leader rilascia ProcArrayLock e quindi riattiva tutti i processi in questo elenco, notificando loro che la transazione è stata completata.
## Probabili cause di aumento delle attese
Maggiore è il numero di processi in esecuzione, più a lungo un leader rimarrà aggrappato procArrayLock a una modalità esclusiva. Di conseguenza, più transazioni di scrittura finiscono in uno scenario di aggiornamento di gruppo, causando un potenziale accumulo di processi in attesa dell'evento di `ProcArrayGroupUpdate` attesa. Nella visualizzazione SQL principale di Database Insights, vedrete che COMMIT è l'istruzione con la maggior parte di questo evento di attesa. Ciò è previsto, ma richiederà un'analisi più approfondita dello specifico SQL di scrittura in esecuzione per determinare l'azione appropriata da intraprendere.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. Identifica `IPC:ProcArrayGroupUpdate` gli eventi utilizzando Amazon RDS Performance Insights o interrogando la vista del sistema PostgreSQL. `pg_stat_activity`
**Topics**
+ [Monitoraggio delle operazioni di conferma e rollback delle transazioni](#apg-rpg-ipcprocarraygroup.actions.monitor)
+ [Ridurre la concorrenza](#apg-rpg-ipcprocarraygroup.actions.concurrency)
+ [Implementazione del pool di connessioni](#apg-rpg-ipcprocarraygroup.actions.pooling)
### Monitoraggio delle operazioni di conferma e rollback delle transazioni
**Monitora i commit e i rollback**: un numero maggiore di commit e rollback può comportare una maggiore pressione su. ProcArray Ad esempio, se un'istruzione SQL inizia a fallire a causa di un aumento delle violazioni di chiavi duplicate, è possibile che si verifichi un aumento dei rollback che può aumentare la contesa e il sovraccarico delle tabelle. ProcArray
Amazon RDS Database Insights fornisce i `xact_commit` parametri di PostgreSQL e riporta il numero di commit `xact_rollback` e rollback al secondo.
### Ridurre la concorrenza
**Transazioni in batch**: ove possibile, operazioni in batch in singole transazioni per ridurre commit/rollback le operazioni.
**Limita la concorrenza**: riduci il numero di transazioni attive contemporaneamente per alleviare la contesa tra blocchi su. ProcArray Sebbene richiederà alcuni test, la riduzione del numero totale di connessioni simultanee può ridurre i conflitti e mantenere la velocità effettiva.
### Implementazione del pool di connessioni
**Soluzioni di pool di connessioni**: utilizza il pool di connessioni per gestire in modo efficiente le connessioni al database, riducendo il numero totale di backend e quindi il carico di lavoro sul. ProcArray Sebbene richieda alcuni test, la riduzione del numero totale di connessioni simultanee può ridurre i conflitti e mantenere la velocità effettiva.
Per ulteriori informazioni, consulta [Connection pooling per Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.connection_pooling.html).
**Riduci le tempeste di connessione**: allo stesso modo, uno schema di creazione e interruzione frequenti delle connessioni causa una pressione aggiuntiva su. ProcArray Riducendo questo modello, si riduce la contesa complessiva.
# Lock:advisory
L’evento `Lock:advisory` si verifica quando un'applicazione PostgreSQL utilizza un blocco per coordinare l'attività su più sessioni.
**Topics**
+ [Versioni di motori pertinenti](#apg-waits.lockadvisory.context.supported)
+ [Context](#apg-waits.lockadvisory.context)
+ [Cause](#apg-waits.lockadvisory.causes)
+ [Azioni](#apg-waits.lockadvisory.actions)
## Versioni di motori pertinenti
Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.
## Context
I blocchi di consulenza PostgreSQL sono blocchi cooperativi a livello di applicazione esplicitamente bloccati e sbloccati dal codice dell'applicazione dell'utente. Un'applicazione PostgreSQL può utilizzare un blocco per coordinare l'attività su più sessioni. A differenza dei normali blocchi a livello di oggetto o riga, l'applicazione ha il pieno controllo sulla durata del blocco. Per ulteriori informazioni consulta [Blocchi di consulenza](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) nella documentazione di PostgreSQL.
I blocchi di consulenza possono essere rilasciati prima della fine di una transazione o essere trattenuti da una sessione tra le transazioni. Ciò tuttavia non è vero per i blocchi impliciti e applicati al sistema, come un blocco esclusivo di accesso su una tabella acquisita da una dichiarazione `CREATE INDEX`.
Per una descrizione delle funzioni utilizzate per acquisire (bloccare) e rilasciare (sbloccare) i blocchi di consulenza, vedere [Funzioni di Advisory Lock](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADVISORY-LOCKS) nella documentazione di PostgreSQL.
I blocchi di consulenza sono implementati sopra il normale sistema di blocco PostgreSQL e sono visibili nella visualizzazione di sistema `pg_locks`.
## Cause
Questo tipo di blocco è controllato esclusivamente da un'applicazione che lo utilizza esplicitamente. I blocchi di consulenza acquisiti per ogni riga come parte di una query possono causare un picco di blocchi o un accumulo a lungo termine.
Questi effetti si verificano quando la query viene eseguita in un modo che acquisisce blocchi su più righe di quelle restituite dalla query. L'applicazione dovrà comunque rilasciare ogni blocco, ma se i blocchi vengono acquisiti su righe che non vengono restituite, l'applicazione non riesce a trovare tutti i blocchi.
L'esempio seguente è tratto da [Blocchi di consulenza](https://www.postgresql.org/docs/12/explicit-locking.html#ADVISORY-LOCKS) nella documentazione di PostgreSQL.
```
SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100;
```
In questo esempio, la clausola `LIMIT` può arrestare l'output della query solo dopo che le righe sono già state selezionate internamente e i relativi valori ID bloccati. Ciò può accadere improvvisamente quando un volume di dati crescente fa sì che il pianificatore scelga un piano di esecuzione diverso che non è stato testato durante lo sviluppo. L'accumulo in questo caso avviene perché l'applicazione chiama esplicitamente `pg_advisory_unlock` per ogni valore ID bloccato. Tuttavia, in questo caso non è possibile trovare il set di blocchi acquisiti su righe che non sono state restituite. Poiché i blocchi vengono acquisiti a livello di sessione, non vengono rilasciati automaticamente alla fine della transazione.
Un'altra possibile causa di picchi nei tentativi di blocco bloccati sono i conflitti non intenzionali. In questi conflitti, parti non correlate dell'applicazione condividono per errore lo stesso spazio ID di blocco.
## Azioni
Esaminare l'utilizzo delle applicazioni dei blocchi di consulenza e i dettagli su dove e quando nel flusso dell'applicazione viene acquisito e rilasciato ogni tipo di blocco consultivo.
Determina se una sessione sta acquisendo troppi blocchi o che una sessione di lunga durata non rilascia blocchi abbastanza presto, causando un lento accumulo di blocchi. È possibile correggere un lento accumulo di blocchi a livello di sessione terminando la sessione utilizzando `pg_terminate_backend(pid)`.
Viene visualizzato un client in attesa di un blocco di avviso in `pg_stat_activity` con `wait_event_type=Lock` e `wait_event=advisory`. È possibile ottenere valori di blocco specifici eseguendo una query nella vista di sistema `pg_locks` per lo stesso `pid`, cercando `locktype=advisory` e `granted=f`.
È quindi possibile identificare la sessione di blocco interrogando `pg_locks` per lo stesso blocco consultivo `granted=t`, come mostrato nell'esempio seguente.
```
SELECT blocked_locks.pid AS blocked_pid,
blocking_locks.pid AS blocking_pid,
blocked_activity.usename AS blocked_user,
blocking_activity.usename AS blocking_user,
now() - blocked_activity.xact_start AS blocked_transaction_duration,
now() - blocking_activity.xact_start AS blocking_transaction_duration,
concat(blocked_activity.wait_event_type,':',blocked_activity.wait_event) AS blocked_wait_event,
concat(blocking_activity.wait_event_type,':',blocking_activity.wait_event) AS blocking_wait_event,
blocked_activity.state AS blocked_state,
blocking_activity.state AS blocking_state,
blocked_locks.locktype AS blocked_locktype,
blocking_locks.locktype AS blocking_locktype,
blocked_activity.query AS blocked_statement,
blocking_activity.query AS blocking_statement
FROM pg_catalog.pg_locks blocked_locks
JOIN pg_catalog.pg_stat_activity blocked_activity ON blocked_activity.pid = blocked_locks.pid
JOIN pg_catalog.pg_locks blocking_locks
ON blocking_locks.locktype = blocked_locks.locktype
AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
AND blocking_locks.pid != blocked_locks.pid
JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
WHERE NOT blocked_locks.GRANTED;
```
Tutte le funzioni API di blocco consultivo hanno due serie di argomenti, un argomento `bigint` o due argomenti `integer`:
+ Per le funzioni API con un argomento `bigint`, i 32 bit superiori sono in `pg_locks.classid` e i 32 bit inferiori sono in `pg_locks.objid`.
+ Per le funzioni API con due argomenti `integer`, il primo argomento è `pg_locks.classid` e il secondo argomento è `pg_locks.objid`.
Il valore `pg_locks.objsubid` indica quale modulo API è stato utilizzato: `1` significa un argomento `bigint`; `2` significa due argomenti `integer`.
# Lock:extend
L’evento `Lock:extend` si verifica quando un processo di back-end è in attesa di bloccare una relazione per estenderla mentre un altro processo ha un blocco su tale relazione per lo stesso scopo.
**Topics**
+ [Versioni del motore supportate](#apg-waits.lockextend.context.supported)
+ [Context](#apg-waits.lockextend.context)
+ [Probabili cause di aumento delle attese](#apg-waits.lockextend.causes)
+ [Azioni](#apg-waits.lockextend.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per tutte el versioni di Aurora PostgreSQL.
## Context
L'evento `Lock:extend` indica che un processo di back-end è in attesa di estendere una relazione su cui un altro processo di backend mantiene un blocco mentre sta estendendo tale relazione. Poiché solo un processo alla volta può estendere una relazione, il sistema genera un evento di attesa `Lock:extend`. Le operazioni `INSERT`, `COPY`, e `UPDATE` possono generare questo evento.
## Probabili cause di aumento delle attese
Quando l'evento `Lock:extend` si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti.
**Aumento degli inserti simultanei o degli aggiornamenti della stessa tabella **
Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella.
**Larghezza di banda di rete insufficiente**
La larghezza di banda di rete sull'istanza database potrebbe essere insufficiente per le esigenze di comunicazione di storage del carico di lavoro corrente. Ciò può contribuire alla latenza dello storage che causa un aumento degli eventi `Lock:extend`.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Riduci gli inserti e gli aggiornamenti simultanei alla stessa relazione](#apg-waits.lockextend.actions.action1)
+ [Aumentare la larghezza di banda di rete](#apg-waits.lockextend.actions.increase-network-bandwidth)
### Riduci gli inserti e gli aggiornamenti simultanei alla stessa relazione
Innanzitutto, determinare se c'è un aumento dei parametri `tup_inserted` e `tup_updated` e un aumento di questi eventi di attesa. In tal caso, verificare quali relazioni sono in forte contesa per le operazioni di inserimento e aggiornamento. Per determinarlo, interrogare la vista `pg_stat_all_tables` per i valori nei campi `n_tup_ins` e `n_tup_upd`. Per ulteriori informazioni sulla vista `pg_stat_all_tables`, consultare [pg\$1stat\$1all\$1tables](https://www.postgresql.org/docs/13/monitoring-stats.html#MONITORING-PG-STAT-ALL-TABLES-VIEW) nella documentazione PostgreSQL.
Per ottenere ulteriori informazioni sul blocco e le query bloccate, eseguire una query `pg_stat_activity` come nel seguente esempio:
```
SELECT
blocked.pid,
blocked.usename,
blocked.query,
blocking.pid AS blocking_id,
blocking.query AS blocking_query,
blocking.wait_event AS blocking_wait_event,
blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
pid | usename | query | blocking_id | blocking_query | blocking_wait_event | blocking_wait_event_type
------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
7143 | myuser | insert into tab1 values (1); | 4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend | IO
```
Dopo aver identificato le relazioni che contribuiscono ad aumentare gli eventi `Lock:extend`, utilizza le seguenti tecniche per ridurre la contesa:
+ Scopri se è possibile utilizzare il partizionamento per ridurre le contese per la stessa tabella. La separazione delle tuple inserite o aggiornate in diverse partizioni può ridurre le contese. Per informazioni sulle partizioni, consulta [Gestione delle partizioni PostgreSQL con l'estensione pg\$1partman](PostgreSQL_Partitions.md).
+ Se l'evento di attesa è dovuto principalmente all'attività di aggiornamento, considerare di ridurre il valore del fattore di riempimento della relazione. Ciò può ridurre le richieste di nuovi blocchi durante l'aggiornamento. Il fattore di riempimento è un parametro di archiviazione per una tabella che determina la quantità massima di spazio per l'imballaggio di una pagina di tabella. Viene espresso come percentuale dello spazio totale per una pagina. Per ulteriori informazioni sul parametro fillfactor, consulta [CREA TABELLA](https://www.postgresql.org/docs/13/sql-createtable.html) nella documentazione di PostgreSQL.
**Importante**
Si consiglia vivamente di testare il sistema se si modifica il fattore di riempimento perché la modifica di questo valore può influire negativamente sulle prestazioni, a seconda del carico di lavoro.
### Aumentare la larghezza di banda di rete
Per vedere se c'è un aumento della latenza di scrittura, controlla il parametro `WriteLatency` in CloudWatch. Se è presente, usa i parametri Amazon CloudWatch `WriteThroughput` e `ReadThroughput` per monitorare il traffico relativo allo storage sul cluster DB. Questi parametri possono aiutarti a determinare se la larghezza di banda della rete è sufficiente per il tuo carico di lavoro.
Se la larghezza di banda della rete non è sufficiente, aumentala. Se il file client o l’istanza DB sta raggiungendo i limiti di larghezza di banda di rete, l'unico modo per aumentare la larghezza di banda è aumentare la dimensione dell'istanza DB.
Per ulteriori informazioni sui parametri CloudWatch, consultare [CloudWatch Parametri Amazon per Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). Per informazioni sulle prestazioni di rete per una classe di istanza database, consulta [Specifiche hardware per le classi di istanze DB per Aurora](Concepts.DBInstanceClass.Summary.md).
# Lock:Relation
L’evento `Lock:Relation` si verifica quando una query è in attesa di acquisire un blocco su una tabella o vista (relazione) attualmente bloccata da un’altra transazione.
**Topics**
+ [Versioni del motore supportate](#apg-waits.lockrelation.context.supported)
+ [Contesto](#apg-waits.lockrelation.context)
+ [Probabili cause di aumento delle attese](#apg-waits.lockrelation.causes)
+ [Azioni](#apg-waits.lockrelation.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
La maggior parte dei comandi PostgreSQL utilizza implicitamente i blocchi per controllare l’accesso simultaneo ai dati nelle tabelle. È inoltre possibile utilizzare questi blocchi esplicitamente nel codice dell’applicazione con il comando `LOCK`. Molte modalità di blocco non sono compatibili tra loro e possono bloccare le transazioni quando cercano di accedere allo stesso oggetto. Quando ciò accade, Aurora PostgreSQL genera un evento `Lock:Relation`. Di seguito sono riportati alcuni esempi comuni:
+ Blocchi esclusivi come `ACCESS EXCLUSIVE` possono bloccare tutti gli accessi simultanei. Le operazioni DDL (Data Definition Language) come `DROP TABLE`, `TRUNCATE`, `VACUUM FULL`, e `CLUSTER` acquisiscono implicitamente i blocchi `ACCESS EXCLUSIVE`. `ACCESS EXCLUSIVE` è anche la modalità di blocco predefinita per le istruzioni `LOCK TABLE` che non specificano esplicitamente una modalità.
+ L’uso di `CREATE INDEX (without CONCURRENT)` su una tabella è in conflitto con le istruzioni DML (Data Manipulation Language) `UPDATE`, `DELETE`, e `INSERT`, che acquisiscono i blocchi `ROW EXCLUSIVE`.
Per ulteriori informazioni sui blocchi a livello di tabella e sulle modalità di blocco in conflitto, vedere [Blocco esplicito](https://www.postgresql.org/docs/13/explicit-locking.html) nella documentazione di PostgreSQL.
Il blocco di query e transazioni in genere si sblocca in uno dei seguenti modi:
+ Query di blocco: l’applicazione può annullare la query o l’utente può terminare il processo. Il motore può anche forzare la fine della query a causa del timeout dell’istruzione di una sessione o di un meccanismo di rilevamento del deadlock.
+ Blocco della transazione: una transazione smette di bloccarsi quando esegue un’istruzione `ROLLBACK` o `COMMIT`. I rollback si verificano automaticamente anche quando le sessioni vengono disconnesse da un client o da problemi di rete o terminano. Le sessioni possono essere terminate quando il motore di database è spento, quando il sistema è fuori memoria e così via.
## Probabili cause di aumento delle attese
Quando l’evento `Lock:Relation` si verifica più frequentemente del normale, può indicare un problema di prestazioni. Le cause tipiche sono:
**Sessioni simultanee aumentate con blocchi di tabella in conflitto**
Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella.
**Operazioni di manutenzione**
Le operazioni di manutenzione Health come `VACUUM` e `ANALYZE` possono aumentare significativamente il numero di blocchi in conflitto. `VACUUM FULL` acquisisce un blocco `ACCESS EXCLUSIVE`, e `ANALYZE` acquisisce un blocco `SHARE UPDATE EXCLUSIVE`. Entrambi i tipi di blocchi possono causare un evento di attesa `Lock:Relation`. Le operazioni di manutenzione dei dati delle applicazioni, come l’aggiornamento di una vista materializzata, possono anche aumentare le query e le transazioni bloccate.
**Blocchi sulle istanze del lettore**
È possibile che si verifichi un conflitto tra i blocchi di relazione tenuti dallo scrittore e dai lettori. Attualmente solo i blocchi di relazione `ACCESS EXCLUSIVE` vengono replicati nelle istanze del lettore. Tuttavia, il blocco di relazione `ACCESS EXCLUSIVE` sarà in conflitto con qualsiasi blocco di relazione `ACCESS SHARE` tenuto dal lettore. Questo conflitto può causare un aumento degli eventi di attesa della relazione di blocco sul lettore.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Riduci l’impatto del blocco delle istruzioni SQL](#apg-waits.lockrelation.actions.reduce-blocks)
+ [Riduci al minimo l’effetto delle operazioni di manutenzione](#apg-waits.lockrelation.actions.maintenance)
+ [Verifica la presenza di blocchi del lettore](#apg-waits.lockrelation.actions.readerlocks)
### Riduci l’impatto del blocco delle istruzioni SQL
Per ridurre l’impatto del blocco delle istruzioni SQL, modificare il codice dell’applicazione laddove possibile. Di seguito sono riportate due tecniche comuni per ridurre i blocchi:
+ Utilizzo dell’opzione `NOWAIT` — Alcuni comandi SQL, come le istruzioni `SELECT` e `LOCK`, supportano questa opzione. La direttiva `NOWAIT` annulla la query richiedente il blocco se il blocco non può essere acquisito immediatamente. Questa tecnica può aiutare a impedire che una sessione di blocco provochi un accumulo di sessioni bloccate dietro di essa.
Ad esempio: si supponga che la transazione A sia in attesa di un blocco trattenuto dalla transazione B. Ora, se B richiede un blocco su una tabella bloccata dalla transazione C, la transazione A potrebbe essere bloccata fino al completamento della transazione C. Ma se la transazione B utilizza un `NOWAIT` quando richiede il blocco su C, può fallire rapidamente e garantire che la transazione A non debba attendere indefinitamente.
+ Utilizza `SET lock_timeout` — Imposta un valore `lock_timeout` per limitare il tempo in cui un’istruzione SQL attende di acquisire un blocco su una relazione. Se il blocco non viene acquisito entro il timeout specificato, la transazione che richiede il blocco viene annullata. Impostare questo valore a livello di sessione.
### Riduci al minimo l’effetto delle operazioni di manutenzione
Operazioni di manutenzione come `VACUUM` e `ANALYZE` sono importanti. Si consiglia di non spegnerli qualora vengano trovati eventi di attesa `Lock:Relation` relativi a queste operazioni di manutenzione. I seguenti approcci possono ridurre al minimo l’effetto di queste operazioni:
+ Eseguire manualmente le operazioni di manutenzione durante le ore non di punta.
+ Per ridurre le attese `Lock:Relation` causate da attività autovacuum, eseguire qualsiasi sintonizzazione automatica necessaria. Per informazioni sulla sintonizzazione autovacuum, fai riferimento a [Funzionamento di PostgreSQL Autovacuum in Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.html) nella *Guida per l’utente di Amazon RDS*.
### Verifica la presenza di blocchi del lettore
Puoi vedere come le sessioni simultanee su uno scrittore e sui lettori potrebbero tenere blocchi che si bloccano a vicenda. A questo scopo, puoi eseguire le query che restituiscono il tipo di blocco e la relazione. Nella tabella è possibile trovare una sequenza di query su due sessioni simultanee, una sessione di scrittura e una sessione di lettura.
Il processo di riproduzione attende la durata impostata per `max_standby_streaming_delay` prima di annullare la query dell’istanza di lettura. Come mostrato nell’esempio, il timeout di blocco di 100 ms è ben al di sotto del valore di default di `max_standby_streaming_delay` di 30 secondi. Il timeout di blocco si verifica prima che si verifichi un problema.
| Evento di sequenza | Sessione | Comando o output |
| --- | --- | --- |
| Imposta una variabile di ambiente denominata READER con il valore specificato e tenta di connettersi all’istanza database con questo endpoint. | Sessione lettore | Comando della CLI: export READER=aurorapg2.12345678910.us-west-1.rds.amazonaws.com
psql -h $READER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| Imposta una variabile di ambiente denominata WRITER e tenta di connettersi all’istanza database con questo endpoint. | Sessione di scrittura | Comando della CLI: export WRITER=aurorapg1.12345678910.us-west-1.rds.amazonaws.com
psql -h $WRITER
Output:
```
psql (15devel, server 10.14)
Type "help" for help.
``` |
| La sessione di scrittura crea la tabella t1 sull’istanza di scrittura. | Sessione di scrittura | Query PostgreSQL: postgres=> CREATE TABLE t1(b integer);
CREATE TABLE
|
| Se non ci sono query in conflitto sullo scrittore, il blocco ACCESS EXCLUSIVE viene acquisito immediatamente sull’istanza di scrittura. | Sessione di scrittura | Blocco `ACCESS EXCLUSIVE` abilitato |
| La sessione del lettore imposta un intervallo di timeout di blocco di 100 millisecondi. | Sessione lettore | Query PostgreSQL: postgres=> SET lock_timeout=100;
SET
|
| La sessione dell’istanza di lettura tenta di leggere i dati dalla tabella t1 sull’istanza di lettura. | Sessione lettore | Query PostgreSQL: postgres=> SELECT * FROM t1;
Output di esempio:
```
b
---
(0 rows)
``` |
| La sessione di scrittura elimina t1. | Sessione di scrittura | Query PostgreSQL: postgres=> BEGIN;
BEGIN
postgres=> DROP TABLE t1;
DROP TABLE
postgres=>
|
| La query scade e viene annullata sul lettore. | Sessione lettore | Query PostgreSQL: postgres=> SELECT * FROM t1;
Output di esempio:
```
ERROR: canceling statement due to lock timeout
LINE 1: SELECT * FROM t1;
^
``` |
| Per determinare la causa dell’errore, la sessione dell’istanza di lettura interroga `pg_locks` e `pg_stat_activity`. | Sessione lettore | Query PostgreSQL: postgres=> SELECT locktype, relation, mode, backend_type
postgres=> FROM pg_locks l, pg_stat_activity t1
postgres=> WHERE l.pid=t1.pid AND relation = 't1'::regclass::oid;
|
| Il risultato indica che il processo `aurora wal replay` è in possesso di un blocco `ACCESS EXCLUSIVE` sulla tabella t1. | Sessione lettore | Risultato della query: locktype | relation | mode | backend_type
----------+----------+---------------------+-------------------
relation | 68628525 | AccessExclusiveLock | aurora wal replay
(1 row)
|
# Lock:transactionid
L’evento `Lock:transactionid` si verifica quando una transazione è in attesa di un blocco a livello di riga.
**Topics**
+ [Versioni del motore supportate](#apg-waits.locktransactionid.context.supported)
+ [Contesto](#apg-waits.locktransactionid.context)
+ [Probabili cause di aumento delle attese](#apg-waits.locktransactionid.causes)
+ [Azioni](#apg-waits.locktransactionid.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
L'evento `Lock:transactionid` si verifica quando una transazione sta tentando di acquisire un blocco a livello di riga già concesso a una transazione in esecuzione contemporaneamente. La sessione che mostra il l'evento di attesa `Lock:transactionid` è bloccato a causa di questo blocco. Dopo che la transazione di blocco termina in un’istruzione `COMMIT` o `ROLLBACK`, la transazione bloccata può procedere.
La semantica multiversione di controllo della concorrenza di Aurora PostgreSQL garantisce che i lettori non bloccano gli scrittori e gli scrittori non bloccano i lettori. Affinché si verifichino conflitti a livello di riga, le transazioni bloccate e bloccate devono emettere dichiarazioni in conflitto dei seguenti tipi:
+ `UPDATE`
+ `SELECT … FOR UPDATE`
+ `SELECT … FOR KEY SHARE`
L’istruzione `SELECT … FOR KEY SHARE` è un caso speciale. Il database utilizza la clausola `FOR KEY SHARE` per ottimizzare le prestazioni dell'integrità referenziale. Un blocco a livello di riga su una fila può bloccare i comandi `INSERT`, `UPDATE`, e `DELETE` su altre tabelle che fanno riferimento alla riga.
## Probabili cause di aumento delle attese
Quando questo evento appare più del normale, la causa è in genere un’istruzione `UPDATE`, `SELECT … FOR UPDATE`, oppure `SELECT … FOR KEY SHARE` combinate con le seguenti condizioni.
**Topics**
+ [Elevata concorrenza](#apg-waits.locktransactionid.concurrency)
+ [Inattivo in transazione](#apg-waits.locktransactionid.idle)
+ [Transazioni di lunga durata](#apg-waits.locktransactionid.long-running)
### Elevata concorrenza
Aurora PostgreSQL può utilizzare la semantica di blocco granulare a livello di riga. La probabilità di conflitti a livello di riga aumenta quando vengono soddisfatte le seguenti condizioni:
+ Un carico di lavoro altamente simultaneo è conteso per le stesse righe.
+ Aumenta la concorrenza.
### Inattivo in transazione
A volte la colonna `pg_stat_activity.state` mostra il valore `idle in transaction`. Questo valore viene visualizzato per le sessioni che hanno avviato una transazione, ma non hanno ancora emesso un `COMMIT` o `ROLLBACK`. Se il valore `pg_stat_activity.state` non è `active`, la query mostrata in `pg_stat_activity` è la versione più recente a terminare l’esecuzione. La sessione di blocco non sta elaborando attivamente una query perché una transazione aperta contiene un blocco.
Se una transazione inattiva ha acquisito un blocco a livello di riga, potrebbe impedire ad altre sessioni di acquisirlo. Questa condizione porta al frequente verificarsi dell'evento di attesa `Lock:transactionid`. Per diagnosticare il problema, esaminare l'output da `pg_stat_activity` e `pg_locks`.
### Transazioni di lunga durata
Le transazioni che vengono eseguite a lungo ricevono blocchi per un lungo periodo di tempo. Questi blocchi a tenuta lunga possono impedire l'esecuzione di altre transazioni.
## Azioni
Il blocco delle righe è un conflitto tra le istruzioni `UPDATE`, `SELECT … FOR UPDATE`, oppure `SELECT … FOR KEY SHARE`. Prima di tentare una soluzione, scopri quando queste istruzioni sono in esecuzione sulla stessa riga. Utilizzare queste informazioni per scegliere una strategia descritta nelle sezioni seguenti.
**Topics**
+ [Rispondere a un'elevata concorrenza](#apg-waits.locktransactionid.actions.problem)
+ [Rispondere alle transazioni inattive](#apg-waits.locktransactionid.actions.find-blocker)
+ [Rispondere alle transazioni di lunga durata](#apg-waits.locktransactionid.actions.concurrency)
### Rispondere a un'elevata concorrenza
Se il problema è la concorrenza, prova una delle seguenti tecniche:
+ Riduci la concorrenza nell'applicazione. Ad esempio, diminuisci il numero di sessioni attive.
+ Implementa un pool di connessioni. Per informazioni su come mettere in pool le connessioni con RDS Proxy, vedere [Proxy Amazon RDS per Aurora](rds-proxy.md).
+ Progettare l'applicazione o il modello di dati per evitare di contendere le istruzioni `UPDATE` e `SELECT … FOR UPDATE`. È inoltre possibile ridurre il numero di chiavi esterne a cui accedono le istruzioni `SELECT … FOR KEY SHARE`.
### Rispondere alle transazioni inattive
Se `pg_stat_activity.state` mostra `idle in transaction`, utilizza le seguenti strategie:
+ Attiva autocommit laddove possibile. Questo approccio impedisce alle transazioni di bloccare altre transazioni durante l'attesa di un `COMMIT` o `ROLLBACK`.
+ Cerca percorsi di codice a cui manca `COMMIT`, `ROLLBACK`, oppure `END`.
+ Assicurati che la logica di gestione delle eccezioni nell'applicazione abbia sempre un percorso per un `end of transaction` valido.
+ Assicurati che l'applicazione elabori i risultati delle query dopo aver terminato la transazione con `COMMIT` o `ROLLBACK`.
### Rispondere alle transazioni di lunga durata
Se le transazioni di lunga durata causano il frequente verificarsi di `Lock:transactionid`, prova le seguenti strategie:
+ Tieni i blocchi di riga fuori dalle transazioni di lunga durata.
+ Limita la durata delle query implementando autocommit quando possibile.
# Lock:tuple
L’evento `Lock:tuple` si verifica quando un processo di backend aspetta di acquisire un blocco su una tupla.
**Topics**
+ [Versioni del motore supportate](#apg-waits.locktuple.context.supported)
+ [Context](#apg-waits.locktuple.context)
+ [Probabili cause di aumento delle attese](#apg-waits.locktuple.causes)
+ [Azioni](#apg-waits.locktuple.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per tutte el versioni di Aurora PostgreSQL.
## Context
L’evento `Lock:tuple` indica che un backend è in attesa di acquisire un blocco su una tupla mentre un altro backend tiene un blocco in conflitto sulla stessa tupla. Nella tabella seguente viene illustrato uno scenario in cui le sessioni generano l’evento `Lock:tuple`.
| Orario | Sessione 1 | Sessione 2 | Sessione 3 |
| --- | --- | --- | --- |
| t1 | Inizia una transazione. | | |
| t2 | Aggiorna la riga 1. | | |
| t3 | | Aggiorna la riga 1. La sessione acquisisce un blocco esclusivo sulla tupla e quindi attende che la sessione 1 rilasci il blocco eseguendo il commit o il rollback. | |
| t4 | | | Aggiorna la riga 1. La sessione attende che la sessione 2 rilasci il blocco esclusivo sulla tupla. |
Oppure puoi simulare questo evento di attesa utilizzando lo strumento di benchmarking `pgbench`. Configurare un numero elevato di sessioni simultanee per aggiornare la stessa riga in una tabella con un file SQL personalizzato.
Per ulteriori informazioni sulle modalità di blocco in conflitto, vedere [Blocco esplicito](https://www.postgresql.org/docs/current/explicit-locking.html) nella documentazione di PostgreSQL. Per ulteriori informazioni su `pgbench`, consulta [pgbench](https://www.postgresql.org/docs/current/pgbench.html) nella documentazione di PostgreSQL.
## Probabili cause di aumento delle attese
Quando l'evento si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti:
+ Un numero elevato di sessioni simultanee sta cercando di acquisire un blocco in conflitto per la stessa tupla eseguendo istruzioni `UPDATE` o `DELETE`.
+ Sessioni altamente simultanee stanno eseguendo un’istruzione `SELECT` usando le modalità di blocco `FOR UPDATE` o `FOR NO KEY UPDATE`.
+ Diversi fattori spingono le applicazioni o i connection pool ad aprire più sessioni per eseguire le stesse operazioni. Mentre le nuove sessioni stanno tentando di modificare le stesse righe, il carico del DB può aumentare e `Lock:tuple` può apparire.
Per ulteriori informazioni consulta [Blocchi a livello di riga](https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS) nella documentazione di PostgreSQL.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa.
**Topics**
+ [Indagare la logica dell’applicazione](#apg-waits.locktuple.actions.problem)
+ [Trova la sessione responsabile del blocco](#apg-waits.locktuple.actions.find-blocker)
+ [Riduci la concorrenza quando è alta](#apg-waits.locktuple.actions.concurrency)
+ [Risoluzione dei problemi dei colli di bottiglia](#apg-waits.locktuple.actions.bottlenecks)
### Indagare la logica dell’applicazione
Scopri se una sessione bloccante è rimasta in stato `idle in transaction` per lungo tempo. In tal caso, considera di terminare la sessione di blocco come soluzione a breve termine. È anche possibile usare la funzione `pg_terminate_backend`. Per ulteriori informazioni su questa funzione, consulta [Funzioni di segnalazione server](https://www.postgresql.org/docs/13/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL) nella documentazione di PostgreSQL.
Per una soluzione a lungo termine, fai quanto seguente:
+ Regola la logica dell'applicazione.
+ Utilizzo del parametro `idle_in_transaction_session_timeout`. Questo parametro termina qualsiasi sessione con una transazione aperta che è rimasta inattiva per un periodo di tempo superiore al periodo di tempo specificato. Per ulteriori informazioni, consulta la pagina [Errori connessione client](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-IN-TRANSACTION-SESSION-TIMEOUT) nella documentazione di PostgreSQL.
+ Usa autocommit il più possibile. Per ulteriori informazioni, consulta la pagina [CONFIGURA AUTOCOMMIT](https://www.postgresql.org/docs/current/ecpg-sql-set-autocommit.html) nella documentazione di PostgreSQL.
### Trova la sessione responsabile del blocco
Mentre si verifica l’evento di attesa `Lock:tuple`, identifica il blocco e la sessione bloccata scoprendo quali blocchi dipendono l'uno dall'altro. Per ulteriori informazioni, consulta [Informazioni sulle dipendenze dei blocchi](https://wiki.postgresql.org/wiki/Lock_dependency_information) nel wiki di PostgreSQL. Per analizzare gli eventi `Lock:tuple` passati, usa la funzione Aurora `aurora_stat_backend_waits`.
L'esempio seguente esegue una query su tutte le sessioni, filtrando su `tuple` e ordinando per `wait_time`.
```
--AURORA_STAT_BACKEND_WAITS
SELECT a.pid,
a.usename,
a.app_name,
a.current_query,
a.current_wait_type,
a.current_wait_event,
a.current_state,
wt.type_name AS wait_type,
we.event_name AS wait_event,
a.waits,
a.wait_time
FROM (SELECT pid,
usename,
left(application_name,16) AS app_name,
coalesce(wait_event_type,'CPU') AS current_wait_type,
coalesce(wait_event,'CPU') AS current_wait_event,
state AS current_state,
left(query,80) as current_query,
(aurora_stat_backend_waits(pid)).*
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
AND usename<>'rdsadmin') a
NATURAL JOIN aurora_stat_wait_type() wt
NATURAL JOIN aurora_stat_wait_event() we
WHERE we.event_name = 'tuple'
ORDER BY a.wait_time;
pid | usename | app_name | current_query | current_wait_type | current_wait_event | current_state | wait_type | wait_event | waits | wait_time
-------+---------+----------+------------------------------------------------+-------------------+--------------------+---------------+-----------+------------+-------+-----------
32136 | sys | psql | /*session3*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000018
11999 | sys | psql | /*session4*/ update tab set col=1 where col=1; | Lock | tuple | active | Lock | tuple | 1 | 1000024
```
### Riduci la concorrenza quando è alta
L’evento `Lock:tuple` potrebbe verificarsi costantemente, soprattutto in un tempo di carico di lavoro occupato. In questa situazione, si consideri di ridurre l'elevata concorrenza per le file molto occupate. Spesso, solo poche righe controllano una coda o la logica booleana, il che rende queste righe molto occupate.
È possibile ridurre la concorrenza utilizzando approcci diversi in base ai requisiti aziendali, alla logica dell'applicazione e al tipo di carico di lavoro. Ad esempio, puoi eseguire le operazioni seguenti:
+ Riprogetta la tua tabella e la logica dei dati per ridurre la concorrenza elevata.
+ Modificare la logica dell'applicazione per ridurre la concorrenza elevata a livello di riga.
+ Sfrutta e riprogetta le query con i blocchi a livello di riga.
+ Utilizzo della clausola `NOWAIT` con operazioni di riprova.
+ Prendi in considerazione l'utilizzo di un controllo della concorrenza logico ottimistico e ibrido.
+ Valuta la possibilità di modificare il livello di isolamento del database.
### Risoluzione dei problemi dei colli di bottiglia
`Lock:tuple` può verificarsi con colli di bottiglia come la fame di CPU o il massimo utilizzo della larghezza di banda Amazon EBS. Per ridurre i colli di bottiglia, valuta i seguenti approcci:
+ Ridimensiona il tipo di classe di istanza.
+ Ottimizza le query a uso intensivo di risorse.
+ Modificare la logica dell'applicazione.
+ Archivia i dati a cui si accede raramente.
# LWLock:contenuto\$1buffer () BufferContent
L’evento `LWLock:buffer_content` si verifica quando una sessione è in attesa di accedere in lettura o scrittura a una pagina dati in memoria mentre un'altra sessione ha bloccato la pagina in scrittura. In Aurora PostgreSQL 13 e versioni successive, questo evento di attesa viene chiamato `BufferContent`.
**Topics**
+ [Versioni del motore supportate](#apg-waits.lockbuffercontent.context.supported)
+ [Contesto](#apg-waits.lockbuffercontent.context)
+ [Probabili cause di aumento delle attese](#apg-waits.lockbuffercontent.causes)
+ [Azioni](#apg-waits.lockbuffercontent.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
Per leggere o manipolare i dati, PostgreSQL vi accede tramite buffer di memoria condivisa. Per leggere dal buffer, un processo ottiene un blocco leggero (LWLock) sul contenuto del buffer in modalità condivisa. Per scrivere sul buffer, ottiene quel blocco in modalità esclusiva. I blocchi condivisi consentono ad altri processi di acquisire contemporaneamente blocchi condivisi su quel contenuto. I blocchi esclusivi impediscono ad altri processi di ottenere qualsiasi tipo di blocco.
L'evento `LWLock:buffer_content` (`BufferContent`) indica che più processi stanno tentando di ottenere blocchi leggeri (LWLocks) sul contenuto di un buffer specifico.
## Probabili cause di aumento delle attese
Quando l’evento `LWLock:buffer_content` (`BufferContent`) si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause tipiche includono le seguenti.
**Aggiornamenti simultanei aumentati degli stessi dati**
Potrebbe esserci un aumento del numero di sessioni simultanee con query che inseriscono o aggiornano la stessa tabella. Questa contesa può essere più marcata sulle tabelle con molti indici.
**I dati del carico di lavoro non sono in memoria**
Quando i dati elaborati dal carico di lavoro attivo non sono in memoria, questi eventi di attesa possono aumentare. Questo effetto è dovuto al fatto che i processi che mantengono i blocchi possono mantenerli più a lungo mentre eseguono operazioni su disco. I/O
**Uso eccessivo di vincoli di chiave esterna**
I vincoli di chiave esterna possono aumentare la quantità di tempo che un processo mantiene su un blocco del contenuto del buffer. Questo effetto è dovuto al fatto che le operazioni di lettura richiedono un blocco del contenuto del buffer condiviso sulla chiave di riferimento mentre quella chiave viene aggiornata.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. Potresti identificare eventi `LWLock:buffer_content` (`BufferContent`) utilizzando Amazon RDS Performance Insights o interrogando la vista `pg_stat_activity`.
**Topics**
+ [Migliora l’efficienza in memoria](#apg-waits.lockbuffercontent.actions.in-memory)
+ [Riduzione dell’utilizzo di vincoli di chiave esterna](#apg-waits.lockbuffercontent.actions.foreignkey)
+ [Rimuovere gli indici inutilizzati](#apg-waits.lockbuffercontent.actions.indexes)
+ [Rimuovere gli indici duplicati](#apg-waits.lockbuffercontent.actions.duplicate-indexes)
+ [Eseguire eliminazione o REINDEX per gli indici non validi](#apg-waits.lockbuffercontent.actions.invalid-indexes)
+ [Utilizzare gli indici parziali](#apg-waits.lockbuffercontent.actions.partial-indexes)
+ [Rimuovere il bloat di tabelle e indici](#apg-waits.lockbuffercontent.actions.bloat)
### Migliora l’efficienza in memoria
Per aumentare la probabilità che i dati del carico di lavoro attivo si trovino in memoria, partizionare tabelle o scalare la classe di istanza. Per informazioni sulle classi di istanza database, consulta [Classi di istanze DB Amazon Aurora](Concepts.DBInstanceClass.md).
Monitorare la metrica `BufferCacheHitRatio`, che misura la percentuale di richieste gestite dalla cache del buffer di un’istanza database nel cluster di database. Questa metrica fornisce informazioni sulla quantità di dati gestiti dalla memoria. Una percentuale di riscontri elevata indica che l’istanza database dispone di memoria sufficiente per il set di dati di lavoro, mentre una percentuale bassa suggerisce che le query accedono frequentemente ai dati dalla risorsa di archiviazione.
I riscontri di lettura nella cache per tabella e i riscontri di lettura nella cache per indice nella sezione Impostazioni memoria del report [PG Collector](https://github.com/awslabs/pg-collector) possono fornire informazioni dettagliate sul rapporto di riscontri nella cache di tabelle e indici.
### Riduzione dell’utilizzo di vincoli di chiave esterna
Indagare sui carichi di lavoro con un numero elevato di eventi di attesa `LWLock:buffer_content` (`BufferContent`) per l’utilizzo di vincoli di chiave esterna. Rimuovere i vincoli di chiave esterna non necessari.
### Rimuovere gli indici inutilizzati
Per carichi di lavoro con un numero elevato di eventi di attesa `LWLock:buffer_content` (`BufferContent`), identificare gli indici inutilizzati e rimuoverli.
La sezione degli indici inutilizzati del report [PG Collector](https://github.com/awslabs/pg-collector) può fornire informazioni dettagliate sugli indici inutilizzati nel database.
### Rimuovere gli indici duplicati
Identificare gli indici duplicati e rimuoverli.
La sezione degli indici duplicati del report [PG Collector](https://github.com/awslabs/pg-collector) può fornire informazioni dettagliate sugli indici duplicati nel database.
### Eseguire eliminazione o REINDEX per gli indici non validi
Gli indici non validi si verificano in genere quando si utilizza `CREATE INDEX CONCURRENTLY` o `REINDEX CONCURRENTLY` e il comando ha esito negativo o viene interrotto.
Gli indici non validi non possono essere utilizzati per le query, ma verranno comunque aggiornati e occuperanno spazio su disco.
La sezione degli indici non validi del report [PG Collector](https://github.com/awslabs/pg-collector) può fornire informazioni dettagliate sugli indici non validi nel database.
### Utilizzare gli indici parziali
Gli indici parziali possono essere utilizzati per migliorare le prestazioni delle query e ridurre le dimensioni dell’indice. Un indice parziale è un indice creato su un sottoinsieme di una tabella, con il sottoinsieme definito da un’espressione condizionale. Come descritto nella documentazione sugli [indici parziali](https://www.postgresql.org/docs/current/indexes-partial.html), gli indici parziali possono ridurre il sovraccarico di gestione degli indici, poiché PostgreSQL non ha bisogno di aggiornare l’indice in tutti i casi.
### Rimuovere il bloat di tabelle e indici
Un eccessivo bloat di tabelle e indici può influire negativamente sulle prestazioni del database. Un bloat delle tabelle e degli indici aumenta le dimensioni del set di lavoro attivo, riducendo l’efficienza della memoria. Inoltre, il bloat aumenta i costi di archiviazione e rallenta l’esecuzione delle query. Per diagnosticare un bloat, consulta [Diagnosi delle dimensioni della tabella e dell'indice](AuroraPostgreSQL.diag-table-ind-bloat.md). Inoltre, la sezione Fragmentation (Bloat) del report [PG Collector](https://github.com/awslabs/pg-collector) può fornire informazioni dettagliate sul bloat di tabelle e indici.
Per risolvere il problema del bloat di tabelle e indici, sono disponibili alcune opzioni:
**VACUUM FULL**
`VACUUM FULL` crea una nuova copia della tabella, copiando solo le tuple attive, quindi sostituisce la vecchia tabella con quella nuova mantenendo un blocco `ACCESS EXCLUSIVE`. Ciò impedisce qualsiasi lettura o scrittura sulla tabella, che può causare un’interruzione. Inoltre, `VACUUM FULL` richiederà più tempo se la tabella è di grandi dimensioni.
**pg\$1repack**
`pg_repack` è utile in situazioni in cui `VACUUM FULL` potrebbe non essere adatto. Crea una nuova tabella che contiene i dati della tabella con bloat, tiene traccia delle modifiche rispetto alla tabella originale e quindi sostituisce la tabella originale con quella nuova. Non blocca la tabella originale per le operazioni di lettura o scrittura durante la creazione della nuova tabella. Per ulteriori informazioni su come utilizzare `pg_repack`, consulta [Rimozione del bloat con pg\$1repack](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/pg-repack.html) e [pg\$1repack](https://reorg.github.io/pg_repack/).
**REINDEX**
Il comando `REINDEX` può essere utilizzato per risolvere il problema del bloat dell’indice. `REINDEX` scrive una nuova versione dell’indice senza le pagine inattive o le pagine vuote o quasi vuote, riducendo così il consumo di spazio dell’indice. Per informazioni dettagliate sul comando [https://www.postgresql.org/docs/current/sql-reindex.html](https://www.postgresql.org/docs/current/sql-reindex.html), consulta la documentazione di REINDEX.
Dopo aver rimosso il bloat dalle tabelle e dagli indici, potrebbe essere necessario aumentare la frequenza dell’autovacuum su tali tabelle. L’implementazione di impostazioni aggressive dell’autovacuum a livello di tabella può aiutare a prevenire il verificarsi di futuri bloat. Per ulteriori informazioni, consulta la documentazione su [https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html](https://docs.aws.amazon.com/prescriptive-guidance/latest/postgresql-maintenance-rds-aurora/autovacuum.html).
# LWLock:mappatura\$1buffer
Questo evento si verifica quando un processo di backend è in attesa di associare un blocco di dati a un buffer nel pool di buffer condiviso.
**Nota**
Questo evento appare come `LWLock:buffer_mapping` in Aurora PostgreSQL versione 12 e versioni successive e `LWLock:BufferMapping` nella versione 13 e successive.
**Topics**
+ [Versioni del motore supportate](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Contesto](#apg-waits.lwl-buffer-mapping.context)
+ [Cause](#apg-waits.lwl-buffer-mapping.causes)
+ [Azioni](#apg-waits.lwl-buffer-mapping.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.
## Contesto
Il *pool buffer condiviso* è un'area di memoria Aurora PostgreSQL che contiene tutte le pagine che sono o sono state utilizzate dai processi. Quando un processo ha bisogno di una pagina, legge la pagina nel buffer pool condiviso. Il parametro `shared_buffers` imposta le dimensioni del buffer condiviso e riserva un'area di memoria per memorizzare la tabella e le pagine indice. Se si modifica questo parametro, assicurarsi di riavviare il database. Per ulteriori informazioni, consulta [Buffer condivisi](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).
L’evento di attesa `LWLock:buffer_mapping` si verifica nei seguenti scenari:
+ Un processo ricerca nella tabella buffer una pagina e acquisisce un blocco di mappatura buffer condiviso.
+ Un processo carica una pagina nel buffer pool e acquisisce un esclusivo blocco di mappatura del buffer.
+ Un processo rimuove una pagina dal pool e acquisisce un blocco esclusivo di mappatura del buffer.
## Cause
Quando questo evento appare più del normale, probabilmente indicando un problema di prestazioni, il database sta eseguendo il paging in entrata e in uscita dal buffer pool condiviso. Le cause tipiche sono:
+ Query di grandi dimensioni
+ Indici e tabelle gonfie
+ Scansioni complete della tabella
+ Dimensioni del pool condiviso più piccole del set di lavoro
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Monitora i parametri relativi al buffer](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Valuta la tua strategia di indicizzazione](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Riduci il numero di buffer che devono essere allocati rapidamente](#apg-waits.lwl-buffer-mapping.actions.buffers)
### Monitora i parametri relativi al buffer
Quando `LWLock:buffer_mapping` aspetta il picco, indaga il rapporto di hit del buffer. È possibile utilizzare questi parametri per comprendere meglio cosa sta accadendo nella cache del buffer. Esamina i seguenti parametri:
`BufferCacheHitRatio`
Questa CloudWatch metrica di Amazon misura la percentuale di richieste servite dalla buffer cache di un'istanza DB nel cluster di database. È possibile che questo parametro diminuisca in anticipo all’evento di attesa `LWLock:buffer_mapping`.
`blks_hit`
Questo parametro contatore Performance Insights indica il numero di blocchi recuperati dal buffer pool condiviso. Dopo che appare l’evento di attesa `LWLock:buffer_mapping`, potresti osservare un picco in `blks_hit`.
`blks_read`
Questa metrica contatore di Performance Insights indica il numero di blocchi che I/O devono essere letti nel pool di buffer condiviso. Potresti osservare un picco in `blks_read` in vista dell’evento di attesa `LWLock:buffer_mapping`.
### Valuta la tua strategia di indicizzazione
Per confermare che la strategia di indicizzazione non sta peggiorando le prestazioni, verifica quanto segue:
Index bloat
Assicurati che il bloat di indice e tabella non porti alla lettura di pagine non necessarie nel buffer condiviso. Se le tabelle contengono righe inutilizzate, considera l'archiviazione dei dati e la rimozione delle righe dalle tabelle. È quindi possibile ricostruire gli indici per le tabelle ridimensionate.
Indici per query utilizzate di frequente
Per determinare se disponi degli indici ottimali, monitora i parametri del motore DB in Performance Insights. Il parametro `tup_returned` mostra il numero di righe lette. Il parametro `tup_fetched` mostra il numero di righe restituite al client. Se `tup_returned` è significativamente più grande di `tup_fetched`, i dati potrebbero non essere indicizzati correttamente. Inoltre, le statistiche della tabella potrebbero non essere aggiornate.
### Riduci il numero di buffer che devono essere allocati rapidamente
Per ridurre gli eventi di attesa `LWLock:buffer_mapping`, cercare di ridurre il numero di buffer che devono essere allocati rapidamente. Una strategia consiste nell'eseguire operazioni di batch di dimensioni ridotte. Potresti essere in grado di ottenere batch più piccoli partizionando le tabelle.
# LWLock:BufferIO (IPC:BufferIO)
L’evento `LWLock:BufferIO` si verifica quando Aurora PostgreSQL o RDS per PostgreSQL sono in attesa che altri processi finiscano le operazioni di input/output (I/O) quando si tenta contemporaneamente di accedere a una pagina. Il suo scopo è quello di leggere la stessa pagina nel buffer condiviso.
**Topics**
+ [Versioni di motori pertinenti](#apg-waits.lwlockbufferio.context.supported)
+ [Context](#apg-waits.lwlockbufferio.context)
+ [Cause](#apg-waits.lwlockbufferio.causes)
+ [Azioni](#apg-waits.lwlockbufferio.actions)
## Versioni di motori pertinenti
Queste informazioni relative all'evento di attesa sono rilevanti per tutte le versioni di Aurora PostgreSQL. Per Aurora PostgreSQL 12 e versioni precedenti questo evento di attesa è denominato lwlock:buffer\$1io mentre in Aurora PostgreSQL versione 13 è denominato lwlock:bufferio. In Aurora PostgreSQL versione 14, l'evento di attesa BufferIO è stato spostato da `LWLock` al tipo di evento di attesa `IPC` (IPC:BufferIO).
## Context
Ogni buffer condiviso ha un blocco I/O associato all’evento di attesa `LWLock:BufferIO`, ogni volta che un blocco (o una pagina) deve essere recuperato all'esterno del buffer pool condiviso.
Questo blocco viene utilizzato per gestire più sessioni che richiedono tutte l'accesso allo stesso blocco. Questo blocco deve essere letto dall'esterno del buffer pool condiviso, definito dal parametro `shared_buffers`.
Non appena la pagina viene letta all'interno del buffer pool condiviso, il blocco `LWLock:BufferIO` viene rilasciato.
**Nota**
L'evento di attesa `LWLock:BufferIO` precede l’evento di attesa [IO: DataFileRead](apg-waits.iodatafileread.md). L’evento di attesa `IO:DataFileRead` si verifica mentre i dati vengono letti dallo storage.
Per ulteriori informazioni sui blocchi leggeri, consulta[Panoramica dei blocchi](https://github.com/postgres/postgres/blob/65dc30ced64cd17f3800ff1b73ab1d358e92efd8/src/backend/storage/lmgr/README#L20).
## Cause
Le cause comuni della comparsa dell'evento `LWLock:BufferIO` che appare nelle prime attese includono:
+ Più backend o connessioni che tentano di accedere alla stessa pagina in attesa di un'operazione di I/O
+ Il rapporto tra le dimensioni del buffer pool condiviso (definito dal parametro `shared_buffers`) e il numero di buffer necessari per il carico di lavoro corrente
+ La dimensione del buffer pool condiviso non è ben bilanciata con il numero di pagine sfrattate da altre operazioni
+ Indici grandi o gonfi che richiedono al motore di leggere più pagine del necessario nel buffer pool condiviso
+ Mancanza di indici che costringe il motore DB a leggere più pagine dalle tabelle del necessario
+ Picchi improvvisi per le connessioni al database che tentano di eseguire operazioni sulla stessa pagina
## Azioni
Consigliamo azioni diverse a seconda delle cause dell'evento di attesa:
+ Osservare i parametri di Amazon CloudWatch per la correlazione tra forti diminuzioni degli eventi di attesa `BufferCacheHitRatio` e `LWLock:BufferIO`. Questo effetto può significare che hai una piccola impostazione dei buffer condivisi. Potrebbe essere necessario aumentarlo o scalare la classe di istanza DB. È possibile dividere il carico di lavoro in più nodi di lettore.
+ Verifica se hai indici inutilizzati, quindi rimuovili.
+ Utilizzare tabelle partizionate (che hanno anche indici partizionati). Ciò aiuta a mantenere basso il riordino dell'indice e ne riduce l'impatto.
+ Evitare di indicizzare inutilmente le colonne.
+ Evita improvvisi picchi di connessione al database utilizzando un connection pool.
+ Limitare il numero massimo di connessioni al database come best practice.
# LWLock:lock\$1manager
Questo evento si verifica quando il motore Aurora PostgreSQL mantiene l'area di memoria del blocco condiviso per allocare, controllare e dislocare un blocco quando non è possibile un blocco rapido del percorso.
**Topics**
+ [Versioni del motore supportate](#apg-waits.lw-lock-manager.context.supported)
+ [Contesto](#apg-waits.lw-lock-manager.context)
+ [Probabili cause di aumento delle attese](#apg-waits.lw-lock-manager.causes)
+ [Azioni](#apg-waits.lw-lock-manager.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per Aurora PostgreSQL versione 9.6 e successive.
## Contesto
Quando si emette un'istruzione SQL, Aurora PostgreSQL registra i blocchi per proteggere la struttura, i dati e l'integrità del database durante le operazioni simultanee. Il motore può raggiungere questo obiettivo utilizzando un blocco veloce del percorso o un blocco del percorso che non è veloce. Un blocco del percorso che non è veloce è più costoso e crea più sovraccarico di un blocco veloce del percorso.
### Blocco rapido del percorso
Per ridurre il sovraccarico dei blocchi che vengono presi e rilasciati frequentemente, ma che raramente sono in conflitto, i processi di backend possono utilizzare il blocco rapido del percorso. Il database utilizza questo meccanismo per i blocchi che soddisfano i seguenti criteri:
+ Usano il metodo di blocco DEFAULT.
+ Rappresentano un blocco su una relazione di database anziché una relazione condivisa.
+ Sono blocchi deboli che difficilmente entrino in conflitto.
+ Il motore può verificare rapidamente che non siano presenti blocchi in conflitto.
Il motore non può utilizzare il blocco rapido del percorso quando una di queste condizioni è vera:
+ Il blocco non soddisfa i criteri precedenti.
+ Non sono disponibili più slot per il processo di backend.
Per ulteriori informazioni sul blocco rapido del percorso, consulta [percorso rapido](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README#L70-L76) nel gestore di blocco PostgreSQL README e [pg-locks](https://www.postgresql.org/docs/15/view-pg-locks.html) nella documentazione di PostgreSQL.
### Esempio di problema di scalabilità per il blocco manager
In questo esempio, una tabella denominata `purchases` memorizza cinque anni di dati, partizionati per giorno. Ogni partizione ha due indici. Si verifica la seguente sequenza di eventi:
1. Si interrogano dati su diversi giorni, il che richiede al database di leggere molte partizioni.
1. Il database crea una voce di blocco per ogni partizione. Se gli indici di partizione fanno parte del percorso di accesso dell'ottimizzatore, il database crea anche una voce di blocco per loro.
1. Quando il numero di voci di blocco richieste per lo stesso processo di back-end è superiore a 16, ovvero il valore di `FP_LOCK_SLOTS_PER_BACKEND`, il gestore di blocco utilizza il metodo di blocco del percorso non veloce.
Le applicazioni moderne potrebbero avere centinaia di sessioni. Se le sessioni simultanee eseguono una query sul genitore senza un'adeguata scrematura delle partizioni, il database potrebbe creare centinaia o addirittura migliaia di blocchi di percorso non veloci. In genere, quando questa concorrenza è superiore al numero di vCPUs, viene visualizzato l'evento di attesa. `LWLock:lock_manager`
**Nota**
L’evento di attesa `LWLock:lock_manager` non è correlato al numero di partizioni o indici in uno schema di database. Al contrario, è correlato al numero di blocchi di percorso non veloci che il database deve controllare.
## Probabili cause di aumento delle attese
Quando l’evento di attesa `LWLock:lock_manager` si verifica più del normale, probabilmente indicando un problema di prestazioni, le cause più probabili di picchi improvvisi sono le seguenti:
+ Le sessioni attive simultanee eseguono query che non utilizzano blocchi di percorso veloci. Queste sessioni superano anche la vCPU massima.
+ Un gran numero di sessioni attive simultanee sta accedendo a una tabella fortemente partizionata. Ogni partizione ha più indici.
+ Il database sta vivendo una tempesta di connessione. Per impostazione predefinita, alcune applicazioni e software del connection pool creano più connessioni quando il database è lento. Questa pratica peggiora il problema. Ottimizza il software del pool di connessioni in modo che non si verifichino tempeste di connessione.
+ Un numero elevato di sessioni esegue una query su una tabella padre senza potare le partizioni.
+ Un DDL (Data Definition Language), DML (Data Manipolation Language) o un comando di manutenzione blocca esclusivamente una relazione occupata o tuple a cui si accede frequentemente o modificate.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa.
**Topics**
+ [Usare la potatura delle partizioni](#apg-waits.lw-lock-manager.actions.pruning)
+ [Rimuovere indici non necessari](#apg-waits.lw-lock-manager.actions.indexes)
+ [Ottimizza le tue query per bloccare rapidamente i percorsi](#apg-waits.lw-lock-manager.actions.tuning)
+ [Sintonizzati per altri eventi di attesa](#apg-waits.lw-lock-manager.actions.other-waits)
+ [Riduzione dei colli di bottiglia hardware](#apg-waits.lw-lock-manager.actions.hw-bottlenecks)
+ [Utilizzare un connection pooler](#apg-waits.lw-lock-manager.actions.pooler)
+ [Aggiorna la versione Aurora PostgreSQL](#apg-waits.lw-lock-manager.actions.pg-version)
### Usare la potatura delle partizioni
*Potatura delle partizioni* è una strategia di ottimizzazione delle query che esclude le partizioni non necessarie dalle scansioni di tabelle, migliorando così le prestazioni. La potatura delle partizioni è attivata per impostazione predefinita. Se è spento, accenderlo come segue.
```
SET enable_partition_pruning = on;
```
Le query possono trarre vantaggio dalla potatura delle partizioni quando la clausola `WHERE` contiene la colonna utilizzata per il partizionamento. Per ulteriori informazioni, consulta [Potatura delle partizioni](https://www.postgresql.org/docs/current/ddl-partitioning.html#DDL-PARTITION-PRUNING) nella documentazione di PostgreSQL.
### Rimuovere indici non necessari
Il database potrebbe contenere indici inutilizzati o usati raramente. In tal caso, considera la possibilità di eliminarli. Esegui una delle operazioni seguenti:
+ Scopri come trovare indici non necessari consultanto [Indici non utilizzati](https://wiki.postgresql.org/wiki/Index_Maintenance#Unused_Indexes) nel wiki di PostgreSQL.
+ Esegui PG Collector. Questo script SQL raccoglie le informazioni del database e le presenta in un report HTML consolidato. Controlla la sezione «Indici non utilizzati». Per ulteriori informazioni, consulta [pg-collector](https://github.com/awslabs/pg-collector) nel repository Labs. AWS GitHub
### Ottimizza le tue query per bloccare rapidamente i percorsi
Per scoprire se le tue query utilizzano il blocco rapido dei percorsi, esegui una query nella colonna `fastpath` della tabella `pg_locks`. Se le query non utilizzano il blocco rapido dei percorsi, provare a ridurre il numero di relazioni per query a meno di 16.
### Sintonizzati per altri eventi di attesa
Se `LWLock:lock_manager` è il primo o il secondo nell'elenco delle prime attese, controlla se nell'elenco vengono visualizzati anche i seguenti eventi di attesa:
+ `Lock:Relation`
+ `Lock:transactionid`
+ `Lock:tuple`
Se gli eventi precedenti appaiono in alto nell'elenco, prendi in considerazione prima l'ottimizzazione di questi eventi di attesa. Questi eventi possono essere un driver per `LWLock:lock_manager`.
### Riduzione dei colli di bottiglia hardware
Potresti avere un collo di bottiglia hardware, come la fame di CPU o il massimo utilizzo della larghezza di banda Amazon EBS. In questi casi, valuta la riduzione dei colli di bottiglia hardware. Prendi in considerazione le seguenti azioni:
+ Ridimensiona la tua classe di istanza.
+ Ottimizza le query che consumano grandi quantità di CPU e memoria.
+ Cambia la logica dell'applicazione.
+ Archivia i tuoi dati.
Per ulteriori informazioni su CPU, memoria e larghezza di banda di rete EBS, vedere [Tipi di istanza Amazon RDS](https://aws.amazon.com/rds/instance-types/).
### Utilizzare un connection pooler
Se il numero totale di connessioni attive supera la vCPU massima, più processi del sistema operativo richiedono CPU di quella supportata dal tipo di istanza. In questo caso, valuta l'utilizzo o l'ottimizzazione di un connection pool. Per ulteriori informazioni sulla v CPUs per il tuo tipo di istanza, consulta [Amazon RDS Instance Types](https://aws.amazon.com/rds/instance-types/).
Per ulteriori informazioni sul connection pool, consulta le risorse seguenti:
+ [Proxy Amazon RDS per Aurora](rds-proxy.md)
+ [pgbouncer](http://www.pgbouncer.org/usage.html)
+ [Connection pool e origini dati](https://www.postgresql.org/docs/7.4/jdbc-datasource.html) nella *Documentazione di PostgreSQL*
### Aggiorna la versione Aurora PostgreSQL
Se la versione attuale di Aurora PostgreSQL è inferiore a 12, esegui l'aggiornamento alla versione 12 o superiore. Le versioni 12 e 13 di PostgreSQL hanno un meccanismo di partizione migliorato. Per ulteriori informazioni sui miglioramenti nella versioni 12, consulta [PostgreSQL 12 Release Notes]( https://www.postgresql.org/docs/release/12.0/). Per ulteriori informazioni sulle versioni di Aurora PostgreSQL, consulta [Aggiornamenti del motore di database Amazon Aurora PostgreSQL per 02/06/2020](AuroraPostgreSQL.Updates.md).
# LWLock:MultiXact
Gli eventi di attesa `LWLock:MultiXactMemberBuffer`, `LWLock:MultiXactOffsetBuffer`, `LWLock:MultiXactMemberSLRU` e `LWLock:MultiXactOffsetSLRU` indicano che una sessione è in attesa di recuperare un elenco di transazioni che modifica la stessa riga di una determinata tabella.
+ `LWLock:MultiXactMemberBuffer`: un processo è in attesa di I/O su un buffer semplice utilizzato meno di recente (SLRU) per un membro multixact.
+ `LWLock:MultiXactMemberSLRU`: un processo è in attesa di accedere alla cache semplice utilizzata meno di recente (SLRU) per un membro multixact.
+ `LWLock:MultiXactOffsetBuffer`: un processo è in attesa di I/O su un buffer semplice utilizzato meno di recente (SLRU) per un offset multixact.
+ `LWLock:MultiXactOffsetSLRU`: un processo è in attesa di accedere alla cache semplice utilizzata meno di recente (SLRU) per un offset multixact.
**Topics**
+ [Versioni del motore supportate](#apg-waits.xactsync.context.supported)
+ [Contesto](#apg-waits.lwlockmultixact.context)
+ [Probabili cause di aumento delle attese](#apg-waits.lwlockmultixact.causes)
+ [Azioni](#apg-waits.lwlockmultixact.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
Un *multixact* è una struttura dati che memorizza un elenco di ID transazione (XID) che modificano la stessa riga della tabella. Quando una singola transazione fa riferimento alla riga di una tabella, l’ID transazione viene memorizzato nella riga di intestazione della tabella. Quando più transazioni fanno riferimento alla stessa riga di una tabella, l’elenco degli ID transazione viene memorizzato nella struttura dati multixact. Gli eventi di attesa multixact indicano che una sessione sta recuperando dalla struttura dei dati l’elenco delle transazioni che fanno riferimento a una determinata riga di una tabella.
## Probabili cause di aumento delle attese
Di seguito sono indicate tre cause comuni dell’uso di multixact:
+ **Sottotransazioni da punti di salvataggio espliciti**: la creazione esplicita di un punto di salvataggio nelle transazioni genera nuove transazioni per la stessa riga. Ad esempio, utilizzando `SELECT FOR UPDATE`, `SAVEPOINT` e quindi `UPDATE`.
Alcuni driver, ORM (Object-Relational Mapper) e livelli di astrazione dispongono di opzioni di configurazione per eseguire automaticamente il wrapping di tutte le operazioni con punti di salvataggio. Questo comportamento può generare molti eventi di attesa multixact in alcuni carichi di lavoro. L’opzione `autosave` del driver PostgreSQL JDBC ne è un esempio. Per ulteriori informazioni, consulta [pgJDBC](https://jdbc.postgresql.org/) nella documentazione di PostgreSQL JDBC. Un altro esempio è il driver PostgreSQL ODBC e l’opzione `protocol`. Per ulteriori informazioni, consulta [psqlODBC Configuration Options](https://odbc.postgresql.org/docs/config.html) (Opzioni di configurazione di psqlODBC) nella documentazione del driver PostgreSQL ODBC.
+ **Sottotransazioni da clausole PL/pgSQL EXCEPTION**: ogni clausola `EXCEPTION` scritta nelle funzioni o procedure PL/pgSQL crea internamente un oggetto `SAVEPOINT`.
+ **Chiavi esterne.** Più transazioni acquisiscono un blocco di condivisione nel record padre.
Quando una determinata riga è inclusa in un’operazione con transazioni multiple, l’elaborazione della riga richiede il recupero degli ID transazione dagli elenchi `multixact`. Se le ricerche non riescono a ottenere il multixact dalla cache di memoria, la struttura dei dati deve essere letta dal livello di archiviazione di Aurora. Questa operazione I/O dall’archiviazione significa che le query SQL possono richiedere più tempo. Gli errori nella cache di memoria possono iniziare a verificarsi con l’utilizzo intensivo, a causa del numero elevato di transazioni multiple. Tutti questi fattori contribuiscono ad un aumento di questo evento di attesa.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. Alcune di queste azioni possono aiutare a ridurre immediatamente gli eventi di attesa. Tuttavia, altre potrebbero richiedere indagini e correzioni per scalare il carico di lavoro.
**Topics**
+ [Eseguire il congelamento del vacuum sulle tabelle con questo evento di attesa](#apg-waits.lwlockmultixact.actions.vacuumfreeze)
+ [Aumentare la frequenza di autovacuum sulle tabelle con questo evento di attesa](#apg-waits.lwlockmultixact.actions.autovacuum)
+ [Aumentare i parametri di memoria](#apg-waits.lwlockmultixact.actions.memoryparam)
+ [Ridurre le transazioni di lunga durata](#apg-waits.lwlockmultixact.actions.longtransactions)
+ [Azioni a lungo termine](#apg-waits.lwlockmultixact.actions.longactions)
### Eseguire il congelamento del vacuum sulle tabelle con questo evento di attesa
Se questo evento di attesa si verifica all’improvviso e influisce sull’ambiente di produzione, è possibile utilizzare uno dei seguenti metodi temporanei per ridurne il numero.
+ Utilizzare *VACUUM FREEZE* sulla tabella o sulla partizione di tabella interessata per risolvere immediatamente il problema. Per ulteriori informazioni, consulta [VACUUM](https://www.postgresql.org/docs/current/sql-vacuum.html).
+ Utilizzare la clausola VACUUM (FREEZE, INDEX\$1CLEANUP FALSE) per eseguire un processo di vacuum rapido saltando gli indici. Per ulteriori informazioni, consulta [Vacuum di una tabella il più rapidamente possibile](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing).
### Aumentare la frequenza di autovacuum sulle tabelle con questo evento di attesa
Dopo aver scansionato tutte le tabelle in tutti i database, VACUUM rimuoverà infine i multixact e i relativi valori multixact meno recenti verranno avanzati. Per ulteriori informazioni, consulta [Multixact e wraparound](https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-MULTIXACT-WRAPAROUND). Per ridurre al minimo gli eventi di attesa LWLock:MultiXact, è necessario eseguire VACUUM tutte le volte che è necessario. A tale scopo, assicurarsi che VACUUM nel cluster di database Aurora PostgreSQL sia configurato in modo ottimale.
Se l’utilizzo di VACUUM FREEZE sulla tabella o sulla partizione di tabella interessata risolve il problema dell’evento di attesa, è consigliabile utilizzare un pianificatore, ad esempio `pg_cron`, per eseguire VACUUM invece di regolare l’autovacuum a livello di istanza.
Per aumentare la frequenza di autovacuum, è possibile ridurre il valore del parametro di archiviazione `autovacuum_multixact_freeze_max_age` nella tabella interessata. Per ulteriori informazioni, consulta [autovacuum\$1multixact\$1freeze\$1max\$1age](https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-MULTIXACT-FREEZE-MAX-AGE).
### Aumentare i parametri di memoria
È possibile ottimizzare l’utilizzo della memoria per le cache multixact regolando i seguenti parametri. Queste impostazioni controllano la quantità di memoria riservata a queste cache, il che può aiutare a ridurre gli eventi di attesa multixact nel carico di lavoro. Per iniziare, è consigliabile utilizzare i seguenti valori:
Per Aurora PostgreSQL 17 e versioni successive:
+ `multixact_offset_buffers` = 128
+ `multixact_member_buffers` = 256
Per Aurora PostgreSQL 16 e versioni precedenti:
+ `multixact_offsets_cache_size` = 128
+ `multixact_members_cache_size` = 256
**Nota**
In Aurora PostgreSQL 17, i nomi dei parametri vengono modificati da `multixact_offsets_cache_size` a `multixact_offset_buffers` e da `multixact_members_cache_size` a `multixact_member_buffers` per allinearli alla versione Community PostgreSQL 17.
È possibile impostare questi parametri a livello di cluster in modo che tutte le istanze del cluster rimangano coerenti. È consigliabile testare e modificare i valori per adattarli al meglio ai requisiti specifici del carico di lavoro e alla classe di istanza. È necessario riavviare l’istanza di scrittura affinché le modifiche ai parametri abbiano effetto.
I parametri sono espressi in termini di voci di cache multixact. Ogni voce di cache utilizza `8 KB` di memoria. Per calcolare la memoria totale riservata, moltiplicare il valore di ogni parametro per `8 KB`. Ad esempio, se si imposta un parametro su 128, la memoria riservata totale sarà `128 * 8 KB = 1 MB`.
### Ridurre le transazioni di lunga durata
Le transazioni di lunga durata fanno sì che le informazioni sulle transazioni vengano mantenute nel vacuum fino al commit della transazione o fino alla chiusura della transazione di sola lettura. Ti consigliamo di monitorare e gestire in modo proattivo le transazioni di lunga durata. Per ulteriori informazioni, consulta [Il database ha una connessione di transazione inattiva da molto tempo](PostgreSQL.Tuning_proactive_insights.md#proactive-insights.idle-txn). Provare a modificare l’applicazione per evitare o ridurre al minimo l’uso di transazioni di lunga durata.
### Azioni a lungo termine
Esaminare il carico di lavoro per scoprire la causa dello spillover multixact. È necessario risolvere il problema per scalare il carico di lavoro e ridurre l’evento di attesa.
+ È necessario analizzare il DDL (Data Definition Language) utilizzato per creare le tabelle. Assicurarsi che le strutture e gli indici delle tabelle siano ben progettati.
+ Se le tabelle interessate hanno chiavi esterne, stabilire se sono necessarie o se esiste un altro modo per applicare l’integrità referenziale.
+ Quando una tabella ha indici inutilizzati di grandi dimensioni, l’autovacuum può non adattarsi al carico di lavoro e potrebbe impedirne l’esecuzione. Per evitare ciò, verificare la presenza di indici non utilizzati e rimuoverli completamente. Per ulteriori informazioni, consulta [Gestione dell’autovacuum con indici di grandi dimensioni](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html).
+ Ridurre l’uso di punti di salvataggio nelle transazioni.
# LWLock:pg\$1stat\$1statements
L'evento di LWLock aspetta:pg\$1stat\$1statements si verifica quando l'estensione blocca in modo esclusivo la tabella hash che tiene traccia delle istruzioni SQL. `pg_stat_statements` Ciò accade nei seguenti scenari:
+ Quando il numero di istruzioni tracciate raggiunge il valore del parametro `pg_stat_statements.max` configurato ed è necessario lasciare spazio a ulteriori voci, l’estensione esegue un ordinamento in base al numero di chiamate, rimuove il 5% delle istruzioni meno eseguite e ripopola l’hash con le voci rimanenti.
+ Quando `pg_stat_statements` esegue un’operazione `garbage collection` sul file `pgss_query_texts.stat` su disco e riscrive il file.
**Topics**
+ [Versioni del motore supportate](#apg-rpg-lwlockpgstat.supported)
+ [Contesto](#apg-rpg-lwlockpgstat.context)
+ [Probabili cause di aumento delle attese](#apg-rpg-lwlockpgstat.causes)
+ [Azioni](#apg-rpg-lwlockpgstat.actions)
## Versioni del motore supportate
Queste informazioni relative all’evento di attesa sono supportate per tutte le versioni di Aurora PostgreSQL.
## Contesto
**Comprendere l’estensione pg\$1stat\$1statements**: l’estensione pg\$1stat\$1statements tiene traccia delle statistiche di esecuzione delle istruzioni SQL in una tabella hash. L’estensione tiene traccia delle istruzioni SQL fino al limite definito dal parametro `pg_stat_statements.max`. Questo parametro determina il numero massimo di istruzioni che possono essere tracciate che corrisponde al numero massimo di righe nella vista pg\$1stat\$1statements.
**Persistenza delle statistiche delle istruzioni**: l’estensione mantiene le statistiche delle istruzioni tra i riavvii dell’istanza mediante:
+ Scrittura di dati in un file denominato pg\$1stat\$1statements.stat
+ Utilizzo del parametro pg\$1statements.save per controllare il comportamento di persistenza
Quando pg\$1statements.save è impostato su:
+ on (impostazione predefinita): le statistiche vengono salvate all’arresto e ricaricate all’avvio del server
+ off: le statistiche non vengono salvate all’arresto né ricaricate all’avvio del server
**Archiviazione del testo delle query**: l’estensione archivia il testo delle query tracciate in un file denominato `pgss_query_texts.stat`. Questo file può aumentare fino a raddoppiare la dimensione media di tutte le istruzioni SQL tracciate prima che si verifichi la rimozione di oggetti inutili. L’estensione richiede un blocco esclusivo sulla tabella hash durante le operazioni di pulizia e riscrittura del file `pgss_query_texts.stat`.
**Processo di deallocazione delle istruzioni**: quando il numero di istruzioni tracciate raggiunge il limite `pg_stat_statements.max` ed è necessario tenere traccia delle nuove istruzioni, l’estensione:
+ Richiede un blocco esclusivo (:pg\$1stat\$1statements) sulla tabella hash. LWLock
+ Carica i dati esistenti nella memoria locale.
+ Esegue un ordinamento rapido in base al numero di chiamate.
+ Rimuove le istruzioni meno chiamate (inferiore al 5%).
+ Ripopola la tabella hash con le voci rimanenti.
**Monitoraggio della deallocazione delle istruzioni**: in PostgreSQL 14 e versioni successive, è possibile monitorare la deallocazione delle istruzioni utilizzando la vista pg\$1stat\$1statements\$1info. Questa visualizzazione include una colonna dealloc che mostra quante volte le istruzioni sono state deallocate per fare spazio a quelle nuove
Se la deallocazione delle istruzioni si verifica frequentemente, ciò comporterà una rimozione di oggetti inutili più frequente del file `pgss_query_texts.stat` su disco.
## Probabili cause di aumento delle attese
Le cause tipiche dell’aumento delle attese di `LWLock:pg_stat_statements` includono:
+ Un aumento del numero di query univoche utilizzate dall’applicazione.
+ Il valore del parametro `pg_stat_statements.max` è piccolo rispetto al numero di query univoche utilizzate.
## Azioni
Consigliamo azioni diverse a seconda delle cause dell’evento di attesa. È possibile identificare gli eventi `LWLock:pg_stat_statements` utilizzando Approfondimenti sulle prestazioni di Amazon RDS o eseguendo una query sulla vista `pg_stat_activity`.
Regola i seguenti `pg_stat_statements` parametri per controllare il comportamento di tracciamento e ridurre gli eventi di attesa delle istruzioni pg\$1stat\$1. LWLock
**Topics**
+ [Disabilitare il parametro pg\$1stat\$1statements.track](#apg-rpg-lwlockpgstat.actions.disabletrack)
+ [Aumentare il parametro pg\$1stat\$1statements.max](#apg-rpg-lwlockpgstat.actions.increasemax)
+ [Disabilitare il parametro pg\$1stat\$1statements.track\$1utility](#apg-rpg-lwlockpgstat.actions.disableutility)
### Disabilitare il parametro pg\$1stat\$1statements.track
Se l'evento di LWLock aspetta:pg\$1stat\$1statements ha un impatto negativo sulle prestazioni del database ed è necessaria una soluzione rapida prima di un'ulteriore analisi della vista `pg_stat_statements` per identificare la causa principale, il parametro può essere disabilitato impostandolo su. `pg_stat_statements.track` `none` In questo modo verrà disabilitata la raccolta delle statistiche sulle istruzioni.
### Aumentare il parametro pg\$1stat\$1statements.max
Per ridurre la deallocazione e minimizzare la rimozione di oggetti inutili del file `pgss_query_texts.stat` su disco, aumentare il valore del parametro `pg_stat_statements.max`. Il valore predefinito è `5,000`.
**Nota**
Il parametro `pg_stat_statements.max` è statico. È necessario riavviare l’istanza database per applicare le modifiche a questo parametro.
### Disabilitare il parametro pg\$1stat\$1statements.track\$1utility
È possibile analizzare la vista pg\$1stat\$1statements per determinare quali comandi di utilità stanno consumando la maggior parte delle risorse monitorate da `pg_stat_statements`.
Il parametro `pg_stat_statements.track_utility` controlla se il modulo tiene traccia dei comandi di utilità, che includono tutti i comandi tranne SELECT, INSERT, UPDATE, DELETE e MERGE. Il valore del parametro è `on` per impostazione predefinita.
Ad esempio, quando l’applicazione utilizza molte query sui punti di salvataggio, che sono intrinsecamente univoche, può aumentare la deallocazione delle istruzioni. Per risolvere questo problema, è possibile disabilitare il parametro `pg_stat_statements.track_utility` per impedire a `pg_stat_statements` di monitorare le query sui punti di salvataggio.
**Nota**
Il parametro `pg_stat_statements.track_utility` è un parametro dinamico. È possibile modificarne il valore senza riavviare l’istanza database.
**Example Esempio di query univoche sui punti di salvataggio in pg\$1stat\$1statements**
```
query | queryid
-------------------------------------------------+---------------------
SAVEPOINT JDBC_SAVEPOINT_495701 | -7249565344517699703
SAVEPOINT JDBC_SAVEPOINT_1320 | -1572997038849006629
SAVEPOINT JDBC_SAVEPOINT_26739 | 54791337410474486
SAVEPOINT JDBC_SAVEPOINT_1294466 | 8170064357463507593
ROLLBACK TO SAVEPOINT JDBC_SAVEPOINT_65016 | -33608214779996400
SAVEPOINT JDBC_SAVEPOINT_14185 | -2175035613806809562
SAVEPOINT JDBC_SAVEPOINT_45837 | -6201592986750645383
SAVEPOINT JDBC_SAVEPOINT_1324 | 6388797791882029332
```
PostgreSQL 17 introduce diversi miglioramenti per il tracciamento dei comandi di utilità:
+ I nomi dei punti di salvataggio vengono ora visualizzati come costanti.
+ La transazione globale IDs (GIDs) dei comandi di commit in due fasi viene ora visualizzata come costanti.
+ I nomi delle istruzioni DEALLOCATE vengono visualizzati come costanti.
+ I parametri CALL vengono ora visualizzati come costanti.
# Timeout: PG Sleep
L’evento `Timeout:PgSleep` si verifica quando un processo server ha chiamato la funzione `pg_sleep` e sta aspettando la scadenza del timeout del sonno.
**Topics**
+ [Versioni del motore supportate](#apg-waits.timeoutpgsleep.context.supported)
+ [Probabili cause di aumento delle attese](#apg-waits.timeoutpgsleep.causes)
+ [Azioni](#apg-waits.timeoutpgsleep.actions)
## Versioni del motore supportate
Queste informazioni relative all'evento di attesa sono supportate per tutte el versioni di Aurora PostgreSQL.
## Probabili cause di aumento delle attese
Questo evento di attesa si verifica quando un'applicazione, una funzione memorizzata o un utente emette un'istruzione SQL che chiama una delle seguenti funzioni:
+ `pg_sleep`
+ `pg_sleep_for`
+ `pg_sleep_until`
Le funzioni precedenti ritardano l'esecuzione fino a quando non è trascorso il numero di secondi specificato. Ad esempio: `SELECT pg_sleep(1)` si ferma per 1 secondo. Per ulteriori informazioni, consulta [Ritardo dell'esecuzione](https://www.postgresql.org/docs/current/functions-datetime.html#FUNCTIONS-DATETIME-DELAY) nella documentazione di PostgreSQL.
## Azioni
Identificare la dichiarazione che stava eseguendo la funzione `pg_sleep`. Determina se l'uso della funzione è appropriato.