DRITA
EnterpriseDB Advanced Server fornisce una serie di funzionalita'
ulteriori rispetto alla versione PostgreSQL Community
per coprire alcuni requisiti delle configurazioni Enterprise.
Per consentire un'analisi dei tempi di attesa delle applicazioni
EDB Advanced Server fornisce il DRITA (Dynamic Runtime Instrumentation Tools Architecture)
che vedremo in questa paginetta.
Nel seguito la pagina e' organizzata nei capitoli seguenti:
Configurazione,
Snapshot,
Reports,
Internals,
Oracle Statspack,
...
Il documento e' volutamente breve e pratico con semplici esempi.
Introduzione
L'analisi dei tempi di attesa sugli eventi interni di una base dati e' una delle tecniche
piu' sofisticate per svolgere l'ottimizzazione ed il tuning.
E' infatti possibile confrontare le attivita' svolte dal motore della base dati
individuando quelle che richiedono un tempo maggiore ed hanno quindi un maggior
impatto sui tempi di risposta.
Ad esempio le attivita' di I/O possono essere distinte tra accessi sequenziali alla heap,
letture sugli indici, scritture dei WAL, ...
Questo tipo di analisi non e' disponibile su tutte le basi dati.
Il Dynamic Runtime Instrumentation Tools Architecture (DRITA)
consente di eseguire sofisticate analisi sulle performance della base dati EDB Postgres Advanced Server,
sia nella configurazione compatibile Oracle che in quella compatibile PostgreSQL.
Configurazione
DRITA e' presente su ogni installazione di EnterpriseDB
e quindi non e' necessaria alcuna installazione.
L'unica impostazione e' il parametro dinamico timed_statistics che puo'
essere impostato nel file di configurazione postgresql.conf oppure con:
SET timed_statistics
Il Dynamic Runtime Instrumentation Tools Architecture (DRITA)
consente di eseguire sofisticate analisi sulle performance della base dati PostgreSQL.
Snapshot
Con la selezione:
SELECT * FROM edbsnap()
viene effettuato uno snapshot che e' l'immagine
di tutte le statistiche raccolte in un certo momento.
Per eseguire un'analisi delle attivita' raccolti piu' snapshot.
Per avere l'elenco degli snapshot la selezione e':
select * from get_snaps()
e con una
Per analizzare il carico di un benchmark tipicamente si effettua uno snapshot all'inizio
ed uno alla fine delle attivita'. Se vi sono momenti o carichi diversi e' possibile
effettuare snapshot interd
medi per analizzare poi ogni singolo intervallo.
Reports
Per generare un report tra due snapshot basta richiamare il comando:
SELECT * FROM sys_rpt(begin_snap, end_snap, 8)
e viene riportato un report dei primi otto eventi di wait occorsi tra i due snapshot indicati.
Ecco un esempio di report (raccolto durante un benchmark OLTP):
WAIT NAME COUNT WAIT TIME % WAIT
---------------------------------------------------------------------------
wal flush 82556 61.912294 33.30
wal write 82569 61.732028 33.21
wal file sync 82561 58.972752 31.72
query plan 66271 3.279333 1.76
db file extend 187 0.014042 0.01
wal insert lock acquire 5 0.000172 0.00
xid gen lock acquire 0 0.000000 0.00
Il report indica chiaramente un bottleneck ovvero una classe di eventi su cui
si concentrano le attese.
E' evidente infatti che e' presente un forte traffico transazionale e che
le attese maggiori sono sulla scrittura dei WAL.
In questo caso per migliorare le prestazioni sara' necessario
eseguire un tuning specifico dei parametri relativi ai WAL
(eg. aumentare il max_wal_size).
Sono disponibili diversi report:
sessid_rpt(begin_snap, end_snap, backend_id)
sesshist_rpt(snap, backend_id)
I report analoghi agli
Oracle Statspack/Automatic Workload Repository (AWR) report sono:
stat_db_rpt()
stat_tables_rpt()
statio_tables_rpt()
stat_indexes_rpt()
statio_indexes_rpt().
La funzione edbreport(, ) li lancia tutti.
Infine per la gestione degli snapshot si utilizzano le funzioni:
truncsnap()
purgesnap(begin_snap, end_snap).
Internals
Per meglio comprendere gli eventi di wait in Postgres e' necessario
conoscere l'architettura interna.
Ciascun processo svolge una serie di compiti precisi ed i tempi di attesa
delle singole attivita' sono raccolti per ogni sessione.
L'elenco completo degli eventi e' riportato nella
documentazione ufficiale
[NdA attenzione alla versione di Postgres: le versioni piu' recenti hanno eventi molto piu' dettagliati].
Oracle Statspack
Chi conosce l'RDBMS Oracle avra' notato una forte somiglianza
con l'utility Statspack presenti dalla versione Oracle 8.1.6.
In effetti l'effettuazione di snapshot, il confronto tra essi,
la produzione di report sono molto, molto simili tra i due strumenti.
Anche il tipo di analisi effettuato, che e' eseguito sui tempi di wait
e' molto simile.
Naturalmente sotto i due motori sono differenti e quindi
gli eventi rilevati sono diversi.
Alcune attivita' sono molto simili: le Sequential Scan delle Heap di Postgres
corrispondono ai Full Table Scan di Oracle,
le scritture sui WAL sono simili a quelle sul Redo Log.
Su entrambe le basi dati l'ottimizzatore deve analizzare gli statement SQL ed ottenere un query plan...
Ma in Postgres non esistono i Rollback Segments ed in Oracle non c'e' la necessita' del VACUUM.
E' noto che lo Statspack e' stato superato in funzionalita'
dall'AWR (Automatic Workload Repository) introdotto nella versione Oracle 10R2.
Pero' lo Statspack e' ancora perfettamente funzionante nella versione Oracle 19c
[NdA attuale versione LTS] ed e' ancora utilizzato perche'
l'AWR non e' disponibile per la Standard Edition e nella Enterprise Edition
e' contenuto nel Diagnostic Pack che e' una
Oracle Option e quindi e' un compomente a pagamento.
Ulteriori informazioni
Un'introduzione a PostgreSQL si trova in PostgreSQL RDBMS.
Maggiori dettagli tecnici sulle diverse versioni di PostgreSQL e le date
di rilascio di ogni versione sono riportate in
questo documento.
Il sito PostgreSQL
contiene tutta la documentazione ufficiale.
Per ogni ulteriore dettaglio e' opportuno fare riferimento alla
documentazione ufficiale.