ZOS:Performances.

Giacomo Restuccia

ZOS:Performances.
Si', qualche osservazione vorrei farla.
1 - Gli accessi di tipo random, che pagano wait per sync-I/O, devono essere
tipici di tabelle piccole, ma molto accedute, o di tabelle grandi con pochi
accessi puntuali
2 - Se proprio non si possono evitare gli accessi random di massa, tentare
laddove possibile di ordinare gli accessi sulla sequenza dei dati in
tabella, per potere sfruttare la possibile dynamic prefetch
3 - Non forzare mai gli accessi sincroni se si hanno predicati con scarso
fattore di filtro
4 - Usare progettualmente e non industrialmente la OPTIMIZE (la LIST
PREFETCH non sempre e' un danno)
5 - E soprattutto.....misurare, misurare, misurare sempre l'utilizzo dei
bufferpool, isolando, se possibile, gli oggetti critici dal punto di vista
dell'I/O.
Infine devo dire che concordo con Luigi; troppo spesso si trascura l'ELAPSED
per curare la CPU, dimenticando che il throughput della macchina aumenta se
si hanno task che non impegnano inutilmente a lungo i threads. Ma e' anche
vero che spesso l'ottimizzazione 'orientata alla CPU time' determina
riduzioni naturali e consistenti dell'elapsed.
Ciao
Giacomo Restuccia

-----Messaggio originale-----
Da: DB2 User Group - Italy List [mailto:[login to unmask email] Per
conto di Gianfelici Luigi
Inviato: 29 November 2004 11:05
A: [login to unmask email]
Oggetto: ZOS: Performances.

Premesso che, mi sembra, si parli spesso di Performance legate
esclusivamente al consumo di CPU (numero di GESTPAGE o numero di DML) ma
troppo poco di quelle legate ai tempi di wait, vorrei porre la seguente
domanda (riferita alla diminuzione di I/O su disco per migliorare il
responso a livello di ELAPSED Time dui vari packages):

quali potrebbero essere i consigli minimi e indispensabili ("tips and
tricks") per avere Bufferpool densi e quali logiche di programmazione
sarebbero da utilizzare (conoscere magari solo le principali...) affinché i
programmi possano ottenere benefici (ad esempio, attivando la Sequential
Detection per dare al DB2 il segnale per attivare Dynamic Prefetch) anche in
termini di consumo di Elapsed Time?

Grazie a tutti quelli che vorranno aiutarmi.

----------------------------
Luigi Gianfelici
S.E.Da. S.p.A.
Telef.: 0731-241250
E-Mail: [login to unmask email]
----------------------------

----------------------------------------------------------------------------
-----
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ
collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2
User Group - Italy può essere raggiunto al seguente indirizzo:
[login to unmask email] Per sapere le ultime novità sulle
conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

Dario Zoso

Re: ZOS:Performances.
(in response to Giacomo Restuccia)
La domanda richiede risposte che dipendono fortemente dall'ambiente
operativo.
In ogni caso è importante:
1) verificare che i programmi con accesso ritenuto random, non abbiano
attivata la Sequential Prefetch a livello di Bind time
2) verificare che i programmi ad accesso sequenziale abbiano la Sequential
Prefetch al Bind time
3) diversificare i bufferpool separando i dati dagli indici, se possibile
4) dedicare un bufferpool a tabelle di sola lettura o poco aggiornamento per
diminuire il numero di I/O

Molte altre cose si potrebbero dire, ma tutto dipende dal tipo di mix DB2.
----- Original Message -----
From: "Giacomo Restuccia" <[login to unmask email]>
To: <[login to unmask email]>
Sent: Monday, December 20, 2004 12:16 PM
Subject: R: ZOS:Performances.


> Si', qualche osservazione vorrei farla.
> 1 - Gli accessi di tipo random, che pagano wait per sync-I/O, devono
> essere
> tipici di tabelle piccole, ma molto accedute, o di tabelle grandi con
> pochi
> accessi puntuali
> 2 - Se proprio non si possono evitare gli accessi random di massa, tentare
> laddove possibile di ordinare gli accessi sulla sequenza dei dati in
> tabella, per potere sfruttare la possibile dynamic prefetch
> 3 - Non forzare mai gli accessi sincroni se si hanno predicati con scarso
> fattore di filtro
> 4 - Usare progettualmente e non industrialmente la OPTIMIZE (la LIST
> PREFETCH non sempre e' un danno)
> 5 - E soprattutto.....misurare, misurare, misurare sempre l'utilizzo dei
> bufferpool, isolando, se possibile, gli oggetti critici dal punto di vista
> dell'I/O.
> Infine devo dire che concordo con Luigi; troppo spesso si trascura
> l'ELAPSED
> per curare la CPU, dimenticando che il throughput della macchina aumenta
> se
> si hanno task che non impegnano inutilmente a lungo i threads. Ma e' anche
> vero che spesso l'ottimizzazione 'orientata alla CPU time' determina
> riduzioni naturali e consistenti dell'elapsed.
> Ciao
> Giacomo Restuccia
>
> -----Messaggio originale-----
> Da: DB2 User Group - Italy List [mailto:[login to unmask email] Per
> conto di Gianfelici Luigi
> Inviato: 29 November 2004 11:05
> A: [login to unmask email]
> Oggetto: ZOS: Performances.
>
> Premesso che, mi sembra, si parli spesso di Performance legate
> esclusivamente al consumo di CPU (numero di GESTPAGE o numero di DML) ma
> troppo poco di quelle legate ai tempi di wait, vorrei porre la seguente
> domanda (riferita alla diminuzione di I/O su disco per migliorare il
> responso a livello di ELAPSED Time dui vari packages):
>
> quali potrebbero essere i consigli minimi e indispensabili ("tips and
> tricks") per avere Bufferpool densi e quali logiche di programmazione
> sarebbero da utilizzare (conoscere magari solo le principali...) affinché
> i
> programmi possano ottenere benefici (ad esempio, attivando la Sequential
> Detection per dare al DB2 il segnale per attivare Dynamic Prefetch) anche
> in
> termini di consumo di Elapsed Time?
>
> Grazie a tutti quelli che vorranno aiutarmi.
>
> ----------------------------
> Luigi Gianfelici
> S.E.Da. S.p.A.
> Telef.: 0731-241250
> E-Mail: [login to unmask email]
> ----------------------------
>
> ----------------------------------------------------------------------------
> -----
> Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
> collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
> Selezionare "Join or Leave the list". Per consultare le IDUG Listserv
> FAQ
> collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2
> User Group - Italy può essere raggiunto al seguente indirizzo:
> [login to unmask email] Per sapere le ultime novità sulle
> conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm
>
> ---------------------------------------------------------------------------------
> Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
> collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
> Selezionare "Join or Leave the list". Per consultare le IDUG Listserv
> FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista
> DB2 User Group - Italy può essere raggiunto al seguente indirizzo:
> [login to unmask email] Per sapere le ultime novità sulle
> conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm
>

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

Adrian Collett

R: ZOS:Performances.
(in response to Dario Zoso)
Ciao Luigi,

Aggiungo anch'io un paio di punti anche se l'argomento richiederebbe una
risposta più esaustiva:

1) Per ridurre i problemi di I/O Sincrono, devi assicurare che i dati
vengono elaborati nello stesso ordine dell'indice clustered e se possibile
elaborarli una sola volta; magari facendo un sort del file di input, o
cambiando il clustering indice; oppure spezzando i programmi in più step con
dei sort intermedi eccetera. Ovviamente, i dati sulla tabella devono essere
effettivamente clusterizzati!!

2) Per quanto riguarda i problemi di bufferpool invece, devi ricordare che
mantenere la pagina in memoria ti da una mano solo se devi ri-leggere la
stessa pagina. Molto spesso nei job batch serale si deve elaborare il dato
una sola volta, e quindi difficilmente la stessa pagina viene riletta.

3) Se vuoi, puoi separare gli oggetti importanti in Bufferpool dedicati a
secondo del loro modo di utilizzo: oggetti acceduti in modo random,
sequenziali, frequente eccetera; oggetti piccoli molto utilizzati possono
essere "pinned" nei buffer pool per ridurre i/o, oppure, ancora meglio in
programmi batch addirittura "pinned" in memoria del programma.

Ciao e Merry Christmas !!

Adrian


-----Messaggio originale-----
Da: DB2 User Group - Italy List [mailto:[login to unmask email] Per
conto di Giacomo Restuccia
Inviato: 20 December 2004 12:16
A: [login to unmask email]
Oggetto: R: ZOS:Performances.

Si', qualche osservazione vorrei farla.
1 - Gli accessi di tipo random, che pagano wait per sync-I/O, devono essere
tipici di tabelle piccole, ma molto accedute, o di tabelle grandi con pochi
accessi puntuali
2 - Se proprio non si possono evitare gli accessi random di massa, tentare
laddove possibile di ordinare gli accessi sulla sequenza dei dati in
tabella, per potere sfruttare la possibile dynamic prefetch
3 - Non forzare mai gli accessi sincroni se si hanno predicati con scarso
fattore di filtro
4 - Usare progettualmente e non industrialmente la OPTIMIZE (la LIST
PREFETCH non sempre e' un danno)
5 - E soprattutto.....misurare, misurare, misurare sempre l'utilizzo dei
bufferpool, isolando, se possibile, gli oggetti critici dal punto di vista
dell'I/O.
Infine devo dire che concordo con Luigi; troppo spesso si trascura l'ELAPSED
per curare la CPU, dimenticando che il throughput della macchina aumenta se
si hanno task che non impegnano inutilmente a lungo i threads. Ma e' anche
vero che spesso l'ottimizzazione 'orientata alla CPU time' determina
riduzioni naturali e consistenti dell'elapsed.
Ciao
Giacomo Restuccia

-----Messaggio originale-----
Da: DB2 User Group - Italy List [mailto:[login to unmask email] Per
conto di Gianfelici Luigi
Inviato: 29 November 2004 11:05
A: [login to unmask email]
Oggetto: ZOS: Performances.

Premesso che, mi sembra, si parli spesso di Performance legate
esclusivamente al consumo di CPU (numero di GESTPAGE o numero di DML) ma
troppo poco di quelle legate ai tempi di wait, vorrei porre la seguente
domanda (riferita alla diminuzione di I/O su disco per migliorare il
responso a livello di ELAPSED Time dui vari packages):

quali potrebbero essere i consigli minimi e indispensabili ("tips and
tricks") per avere Bufferpool densi e quali logiche di programmazione
sarebbero da utilizzare (conoscere magari solo le principali...) affinché i
programmi possano ottenere benefici (ad esempio, attivando la Sequential
Detection per dare al DB2 il segnale per attivare Dynamic Prefetch) anche in
termini di consumo di Elapsed Time?

Grazie a tutti quelli che vorranno aiutarmi.

----------------------------
Luigi Gianfelici
S.E.Da. S.p.A.
Telef.: 0731-241250
E-Mail: [login to unmask email]
----------------------------

----------------------------------------------------------------------------
-----
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ
collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2
User Group - Italy può essere raggiunto al seguente indirizzo:
[login to unmask email] Per sapere le ultime novità sulle
conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

----------------------------------------------------------------------------
-----
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione
collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html.
Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ
collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2
User Group - Italy può essere raggiunto al seguente indirizzo:
[login to unmask email] Per sapere le ultime novità sulle
conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm

Max Scarpa

Re: ZOS:Performances.
(in response to Adrian Collett)
Spedito di nuovo perchè nel precedente mancava il subject. Chiedo
venia.....

__________________

Personalmente ho visto diversi casi dove varie applicazioni, pur navigando
in un mare di CPU, avevano elevati elapsed per wait (principalmente I/O).

E non sempre il wait è 'nativo' del disco ma spesso è causato da canali
'overloaded' (ESCON, i FICON hanno performance decisamente migliori)
associati a problemi di disk cache. E' vero che spesso altri fattori di
wait (per esempio log waits, latch waits etc) sono poco considerati, ma di
solito perchè per il DASD MANAGER è sempre 'tutto ok' e chi mastica DB2 di
solito mastica poco di DASD. E' altrettanto vero che cash floods derivano
da SQL poco 'filtranti' che inondano disk cache e bufferpool di pagine
dati, magari inutili, specialmente nei casi di BP poco 'caratterizzati'. E
che magari devono essere comunque passati (inutilmente) a RDS per via
della query.

Al di là del bufferpool tuning (ti raccomando gli eccellenti articoli di
Chuck Hooover e di J. Goldstein) con la separazione tra dati e indici e tra
oggetti sequenziali e random (oltre che per DSNDB07 e 'tabelle in-memory')
va sempre fatta un'attenta analisi dell'ACCOUNTING classe 3 degli heavy
hitters, ovvero dei programmi più pesanti che girano nel sistema. Un ottimo
articolo relativo ai waits è quello di Namik Hrle dell'IDUG 2001. Senza
dimenticare le prestazioni del sort in ambienti quali datawarehouse, QMF
etc. Utilissima è l'analisi dei record SMF 42-6 e anche delle IFCIDs 6/7
in associazione.

Non va dimenticato, oramai, di dare una controllatina alle classificazioni
WLM del sottosistema DB2 e delle varie applicazioni. Talvolta i batch DB2
(i classici I/O intensive) sono classificati con priorità (relativamente)
basse innescando altri wait al di fuori del DB2.

Solo alcune brevi considerazioni.

Max Scarpa

DB2 sysprog
Dasd Manager
WLM administrator

PS Se qualcuno è a conoscenza di ricerce di personale sistemistico DB2 o
z/OS nell'area VE//PD/TV o comunque in aree raggiungibili in tempo
regionevole me lo può segnalare ? Grazie in anticipo.









---------------------------------------------------------------------------------
Benvenuti alla lista DB2 User Group Italia.Per annullare l ' iscrizione collegarsi a : http://www.idugdb2-l.org/archives/DB2-UG-Italy.html. Selezionare "Join or Leave the list". Per consultare le IDUG Listserv FAQ collegarsi a :http://www.idugdb2-l.org. L'amministratore della lista DB2 User Group - Italy può essere raggiunto al seguente indirizzo: [login to unmask email] Per sapere le ultime novità sulle conferenze IDUG potete consultare : http://conferences.idug.org/index.cfm