Le attivita' di ottimizzazione e tuning di sistemi sono complesse e richiedono esperienze specifiche. In questo documento vengono esaminati gli aspetti generali dell'ottimizzazione e del tuning di un sistema.
Il sistema di riferimento e' un sever Unix con un RDBMS Oracle che ospita applicazioni locali ed in client/server. Tuttavia le indicazioni fornite ed i riferimenti presenti hanno validita' generale.
L'attivita' di ottimizzazione viene svolta per migliorare le prestazioni di un sistema al momento del disegno iniziale. Naturalmente tale attivita' richiede esperienze specifiche poiche' e' necessario valutare possibilita' diverse con diversi impatti su tutto il sistema (p.e. un programma puo' essere realizzato con algoritmi diversi, gli algoritmi piu' efficienti spesso richiedono maggior memoria o spazio su disco o altre risorse di sistema).
L'attivita' di tuning viene invece svolta su ogni singola implementazione o realizzazione. Un sistema e' spesso composto da piu' parti, tutte con un certo grado di configurabilita' e di parametrizzazione. Con il tuning si cerca di trovare il compresso migliore tra tutti gli elementi configurabili del sistema. Il monitoraggio del sistema e' fondamentale per il tuning, il tuning dovra' essere svolto ogni qualvolta il valori monitorati diano indicazioni in tal senso.
Volendo entrare in maggior dettaglio sugli aspetti che riguardano un sistema reale, e' importante riconoscere la presenza di piu' livelli su cui e' possibile effettuare interventi di ottimizzazione e di tuning.
L'ordine utilizzato e' guidato dall'impatto prestazionale che l'intervento su tale livello puo' generare.
E' di notevole importanza approcciare i problemi di prestazioni agendo al giusto livello. Agendo su elementi gia' ben definiti o ottimizzati si possono ottenere miglioramenti che hanno un livello di grandezza minore nell'impatto finale all'utente.
Quando si sviluppano programmi che accedono a base dati complesse, di notevoli dimensioni, con elementi distribuiti o con accessi particolare (ed in questo progetto si verificano tutte queste condizioni) e' di fondamentale importanza il controllo delle prestazioni. Per un efficace controllo dei programmi e' necessaria la costruzione di basi dati di test di ampiezza sufficiente ed effettuare quindi test sui volumi. In tal modo e' possibile un immediato riscontro sulle tempistiche di accesso ai dati.
Nei capitoli seguenti verranno esaminati alcuni elementi sulla corretta metodologia. Infine verranno riportati i principali elementi relativi ad alcuni dei livelli di ottimizzazione definiti precedentemente.
Per quanto riguarda il miglioramento delle prestazioni la strategia da seguire per ottenere buoni risultati e' guidata da alcune considerazioni.
E' necessario escludere i programmi poco utilizzati o poco strategici; escludere i programmi che, seppure migliorabili, siano gia' sufficientemente prestanti; evitare di modificare parti che richiederebbero modifiche al sistema troppo onerose.
Per ottenere risultati concreti bisogna definire con chiarezza gli obiettivi e concentrarsi su quelli. Non ha senso parlare di miglioramento delle prestazioni in assoluto. Vi sono limiti oltre ai quali non conviene assolutamente scendere, anche perche' il massimo delle prestazioni da un sistema si ottiene solo a discapito di altri elementi (sicurezza, semplicita', flessibilita', ..).
Una volta definiti i punti su cui intervenire e l'obiettivo da raggiungere e' opportuno seguire una metodologia corretta di analisi e risoluzione del problema.
Anche se quanto segue non e' completamente rigoroso, il tipo di attivita' da svolgere per ogni intervento di ottimizzazione puo' essere cosi' riassunto:
studio delle informazioni coinvolte nel processo e dei programmi realizzati
valutazione rigorosa delle prestazioni, sia complessive che di parti significative dei programmi nella versione attuale
preparazione elenco puntuale di proposte di modifica
valutazione di ogni singola proposta, esecuzione di quanto eseguibile immediatamente, valutazione impatto sui programmi, registrazione tempi
preparazione prototipo con modifiche sui programmi
valutazione dei tempi e confronto
implementazione effettiva
I passi elencati debbono essere eseguiti per ogni intervento individuato. L'individuazione dei singoli interventi non e' banale (poiche' richiede soprattutto esperienza specifica) ed e' di difficile preventivazione. Quello che generalmente avviene e' che, dopo alcuni riclicli iniziali, l'impatto sulle prestazioni e' via via minore fino a divenire irrilevante. E' possibile che alcuni interventi richiedano un onere tale per l'implementazione da suggerire il rinvio ad una successiva versione dei programmi.
Il disegno logico della base dati deve essere effettuato tenendo in dovuto conto gli aspetti prestazionali del sistema finale.
Oltre alla necessaria normalizzazione iniziale di tutti i dati e' pertanto necessario verificare l'esigenza di introdurre ulteriori elementi di ottimizzazione quali:
la denormalizzazione dei dati (per porli dove vengono piu' frequentemente o facilmente acceduti)
la overnormalizzazione dei dati (per rendere piu' snelle le strutture dati piu' frequentemente accedute).
Tali attivita' vengono effettuate creando ridondanza nel database e gestendo correttamente tali strutture dati negli applicativi.
Poiche' l'impatto applicativo puo' essere forte ed elevato e' il rischio di disallineamenti sui dati le operazioni suggerite debbono essere svolte solo nei casi necessarie ed adeguatamente documentate.
Il disegno logico della base dati riguarda le strutture fisiche su cui si poggia l'RDBMS.
Un veloce elenco di consigli e' il seguente:
Utilizzare dischi, I/O processor, catene SCSI ... il piu' possibile distinti per la memorizzazione dei dati dell'RDBMS.
E' in genere opportuno l'utilizzo di raw devices
Creare tablespace distinti per tabelle, indici, rollback e temporanei. La creazione di una partizione SYSTEM distinta offre vantaggi dal punto di vista di gestione.
Quando la dimensione delle tabelle e' elevata utilizzare lo striping.
Definire in maniera corretta il dimensionamento di tutte le strutture dati. Tutti gli oggetti dovrebbero avere un solo extent (eccezione fatta per lo striping e per i rollback i cui extents dovrebbero essere 2).
Definire correttamente l'allocazione dei temporanei.
Utilizzare i cluster se vi sono tabelle frequentemente accedute insieme e con cardinalita' ben definita.
Creare tutti i necessari indici prestazionali (colonne utilizzate nelle selezioni con l'ordine corretto, con un elevato grado di selettivita' [>20%]).
Utilizzare colonne di piccole dimensioni negli indici.
Evitare assolutamente la definizione di indici non utilizzati. Il peso in modifica e' elevato.
Il linguaggio SQL e' apparentemente molto semplice, tuttavia per sfruttare appieno le possibilita' che offre e' necessario conoscerne profondamente le particolarita' e gli elementi specifici che ogni diversa implementazione puo' presentare.
I diversi RDBMS presenti sul mercato offrono diverse estensioni del linguaggio SQL che comprendono nuove clausole e funzioni di utilita'.
Anche dal punto di vista del miglioramento delle prestazioni gli ottimizzatori offrono parecchie funzionalita'.
Fare riferimento al documento Ottimizzazione degli statement SQL per maggiori informazioni.
Oracle ha un numero molto elevato di parametri di configurazione (peraltro non tutti documentati) e consente diversi tipi e modalita' d'installazione. Questo rende l'attivita' di tuning potenzialmente complessa. Tuttavia tale attivita' e' spesso molto efficace.
L'attivita' di tuning sull'RDBMS Oracle richiede una serie di ricicli sui seguenti passi:
controllo dell'andamento del sistema in configurazione e con carico reale
determinazione degli eventuali colli di bottiglia presenti
modifica dei relativi parametri di configurazione
I passi elencati debbono essere svolti ripetutamente controllando i diversi aspetti di impatto sulle performances. Il monitoring del database dovrebbe essere costante; un buon DBA (database administrator) ha costantemente presente la situazione corrente del database. E' sempre necessaria la stretta collaborazione con i sistemisti del sistema che ospita l'RDBMS; spesso infatti i parametri di Oracle hanno effetti sulle prestazioni dell'intero sistema.
Gli strumenti per effettuare il monitoring dell'RDBMS Oracle utilizzabili sono:
statement SQL sul data dictionary
sqldba/monitor
trace
tool di terze parti.
Fare riferimento al documento Statistiche prestazionali di Oracle per maggiori elementi sul tuning dell'RDBMS Oracle.
Anche per il tuning del sistema, utilizzato come ospite di un RDBMS, e' opportuno seguire la metodologia indicata precedentemente.
Gli strumenti per effettuare il monitoring dell'RDBMS da utilizzare sono le normali utilities Unix (sar, ps, df, ..). Alcuni sistemi offrono strumenti piu' sofisticati, tale situazione non e' tuttavia frequente.
I punti su cui e' opportuno concentrarsi sono:
memoria: controllando l'assenza di swapping, le dimensioni delle varie shared memory allocate e la buffer cache
I/O: controllando il corretto bilanciamento dei carichi sui dischi e la presenza di spazio libero, evitando la frammentazione dei dischi
cpu: valutando il carico (ed il tipo di carico) in momenti con attivita' di tipo diverso
processi: valutando il numero, il tipo ed il job mix
In genere i sistemi su cui non e' stato effettuato il tuning presentano alcuni bottleneck. Generalmente un tuning corretto consente di limitarne l'impatto sulle prestazioni complessive del sistema. L'individuazione dei bottleneck e' un punto fondamentale della fase di tuning del sistema.
Quali elementi di stima per una corretta individuazione possono essere utili i seguenti spunti (che sono validi per la maggioranza dei sistemi unix):
L'idle di CPU non deve essere costantemente a 0. (CPU bound)
La coda di run-queue non deve superare 1 per lungo tempo. (CPU bound)
Il tempo di System di CPU deve essere in genere minore del tempo User. (controllare la tipologia di attivita')
I virtual fault di paginazione dovrebbero essere limitati. (Memory bound)
La principale attivita' di paginazione deve essere di page-in. (Memory bound)
L'attivita' del page stealer deve essere limitata. (Memory bound)
Non deve essere presente swapping. (Memory bound, job mix)
Le code sui dischi debbono essere vicine ad 1. (IO bound)
I dischi debbono essere utilizzati in maniera bilanciata. (bilanciamento IO)
I tempi di accesso ai dischi debbono essere vicini ai tempi medi di accesso dichiarati dal costruttore (troppe seek, modificare il partizionamento dei dischi).
Il numero di interventi possibili e' comunque limitato dalle possibilita' di configurazione di Unix. Le principali attivita' possibili sono:
riduzione del kernel Unix
creazione del corretto job mix da presentare alla macchina
definizione corretta delle aree di paginazione e di swapping
bilanciamento dei carichi sui dischi
diminuzione del seeking dei dischi
tuning sui parametri di sistema (buffering, paginazione, ()..)
Testo: Ottimizzazione e tuning
Data: 27 Maggio 1997
Versione: 1.0.2
Autore: mail@meo.bogliolo.name