Translation

The oldest posts, are written in Italian. If you are interested and you want read the post in English, please use Google Translator. You can find it on the right side. If the translation is wrong, please email me: I'll try to translate for you.

venerdì, febbraio 26, 2016

CPU count (ENG)

  • HP-UX (B.11.11)

[oracle]$/usr/sbin/ioscan  -knfC processor |grep processor |wc -l
      8
 
[oracle]$/usr/sbin/ioscan  -knfC processor

Class       I  H/W Path  Driver    S/W State H/W Type  Description
===================================================================
processor   0  4/10      processor CLAIMED   PROCESSOR Processor
processor   1  4/11      processor CLAIMED   PROCESSOR Processor
processor   2  4/12      processor CLAIMED   PROCESSOR Processor
processor   3  4/13      processor CLAIMED   PROCESSOR Processor
processor   4  6/10      processor CLAIMED   PROCESSOR Processor
processor   5  6/11      processor CLAIMED   PROCESSOR Processor
processor   6  6/12      processor CLAIMED   PROCESSOR Processor
processor   7  6/13      processor CLAIMED   PROCESSOR Processor



  • Solaris
[oracle]$/usr/sbin/psrinfo |wc -l
      32


[oracle]$/usr/sbin/psrinfo 
0       on-line   since 02/12/2016 09:57:19
1       on-line   since 02/12/2016 09:57:21
2       on-line   since 02/12/2016 09:57:21
3       on-line   since 02/12/2016 09:57:21
8       on-line   since 02/12/2016 09:57:21
9       on-line   since 02/12/2016 09:57:21
10      on-line   since 02/12/2016 09:57:21
11      on-line   since 02/12/2016 09:57:21
16      on-line   since 02/12/2016 09:57:21
17      on-line   since 02/12/2016 09:57:21
18      on-line   since 02/12/2016 09:57:21
19      on-line   since 02/12/2016 09:57:21
24      on-line   since 02/12/2016 09:57:21
25      on-line   since 02/12/2016 09:57:21
26      on-line   since 02/12/2016 09:57:21
27      on-line   since 02/12/2016 09:57:21
32      on-line   since 02/12/2016 09:57:21
33      on-line   since 02/12/2016 09:57:21
34      on-line   since 02/12/2016 09:57:21
35      on-line   since 02/12/2016 09:57:21
36      on-line   since 02/12/2016 09:57:21
37      on-line   since 02/12/2016 09:57:21
38      on-line   since 02/12/2016 09:57:21
39      on-line   since 02/12/2016 09:57:21
40      on-line   since 02/12/2016 09:57:21
41      on-line   since 02/12/2016 09:57:21
42      on-line   since 02/12/2016 09:57:21
43      on-line   since 02/12/2016 09:57:21
44      on-line   since 02/12/2016 09:57:21
45      on-line   since 02/12/2016 09:57:21
46      on-line   since 02/12/2016 09:57:21
47      on-line   since 02/12/2016 09:57:21



  • Linux 
[oracle]$cat /proc/cpuinfo|grep processor|wc -l
      16

[oracle]$/sbRdbms/oracle-$cat /proc/cpuinfo|grep processor
processor       : 0
processor       : 1
processor       : 2
processor       : 3
processor       : 4
processor       : 5
processor       : 6
processor       : 7
processor       : 8
processor       : 9
processor       : 10
processor       : 11
processor       : 12
processor       : 13
processor       : 14
processor       : 15



  • AIX (6.1 verified)
[oracle]$/bin/lparstat |head -2| sed '/^$/d'| awk '{print $6}'
lcpu=16

[oracle]$/bin/pmcycles -m
CPU 0 runs at 3864 MHz
CPU 1 runs at 3864 MHz
CPU 2 runs at 3864 MHz
CPU 3 runs at 3864 MHz
CPU 4 runs at 3864 MHz
CPU 5 runs at 3864 MHz
CPU 6 runs at 3864 MHz
CPU 7 runs at 3864 MHz
CPU 8 runs at 3864 MHz
CPU 9 runs at 3864 MHz
CPU 10 runs at 3864 MHz
CPU 11 runs at 3864 MHz
CPU 12 runs at 3864 MHz
CPU 13 runs at 3864 MHz
CPU 14 runs at 3864 MHz
CPU 15 runs at 3864 MHz


  • Update (15/Mar/2016)

From Oracle point of view, in order to obtains the CPU count, you have to query V$OSSTAT. This view exist from Oracle 10g onwards. Normally the value you use is NUM_CPUS

[Linux] select stat_name, value from  v$osstat where stat_name like '%CPU%';

STAT_NAME                           VALUE
------------------------------ ----------
NUM_CPUS                               16 <<< correct value
RSRC_MGR_CPU_WAIT_TIME                 43
NUM_CPU_CORES                          16
NUM_CPU_SOCKETS                        16


Anyway, on AIX platform, because the "Bug 14215038 : CPU_COUNT DOESN'T MATCH", you need to use different column

[AIX] select stat_name, value from  v$osstat where stat_name like '%CPU%';

STAT_NAME                           VALUE
------------------------------ ----------
NUM_CPUS                               44 <<< wrong value due to 14215038 Bug
OS_CPU_WAIT_TIME               3.3043E+10
RSRC_MGR_CPU_WAIT_TIME                  0
NUM_CPU_CORES                          10
NUM_VCPUS                              10 <<< correct Virtual CPU number
NUM_LCPUS                              20 <<< correct Logical CPU number


If you compare this output with the "AIX (6.1 verified)", you see that the NUM_CPUS column cointain a wrong value.


  • Update 2016/Jun/13

Modified the /usr/sbin/ioscan output. It counted wrong the CPU processors number
  • Reference
Physical - Virtual - Logical CPU

mercoledì, febbraio 17, 2016

DB Time (3 di 3) (ITA)

DB Time (1 di 3)
DB Time (2 di 3)

Il “database time” è il tempo totale speso dall’utente o a lavorare “attivamente” oppure ad aspettare “attivamente” in una “database call” (una “db call” è una funzione C nel kernel di Oracle. Se abilitiamo il “training” di una sessione, osserviamo che il kernel stampa una stringa nel file di output, al completamento della “database call”. Le più comuni sono PARSE, EXEC e FETCH).

- Relazione tra “System Load” e “DB Time”
Più utenti => Più “DB call” => il “DB time” aumenta Grandi transazioni => “DB call” più lunghe => il “DB time” aumentA
 -> Il DB time aumenta, all’aumentare del carico di lavoro del sistema

- Relazione tra le performance di un sistema ed il "DB Time"
Le prestazioni di I/O degradano => il tempo di I/O aumenta => il DB time aumenta Le prestazioni applicative degradano => il Wait time aumenta => il DB time aumenta
-> Il DB time aumenta quando le prestazioni.

- Relazione tra le prestazioni di una macchina ed il “DB Time”
Se le CPU della macchina sono eccessivamente attive => i processi foregrounds accumulano “tempo attivo” in run-queue => i tempi di attesa so artificialmente gonfiati => il DB time aumenta
-> Il db Time aumenta quando il le CPU fanno un eccessivo lavoro

Migliorare le prestazioni vuol dire fare lo stesso lavoro in meno “DB Time”, vuol dire cioè rimuovere l’ecceo di “DB Tme”.

Il “Database time” è semplicemente una misura de lavoro fatto dal database. Volendo fare un’analogia, possiamo dire che è l’equivalente dell’unita di misura “Joule” usata in Fisica nel Sistema Internazionale, per misurare l’energia (lavoro fatto da un sistema).

La velocità con cui il “Database Time” è consumato, è il “load average” del database analogo a quello del Sistema Operativo. L’unità di misura di tale velocità, ‘Database Time’/sec, è analoga al “Watt” o a “Joule/sec” nel SI, per misurare la potenza. Poiché l’obiettivo è quello di ridurre la quantità di tempo speso per un certo workload, questo è analogo al consumare meno energia per eseguire lo stesso compito.

  • Update (16/Mar/2016)
Ho aggiunto nuovi documenti come riferimento

Riferimenti

DB Time (2 di 3)

DB Time (2 di 3) (ITA)

DB Time (1 di 3)
DB Time (3 di 3)

DB Time = CPU Time + Wait Time

è l’equazione che lega le principali componenti nel database:
- tempo di lavoro
- tempo di attesa

La stessa equazione possiamo anche riscriverla come (dividendo per DB Time e moltiplicando per 100)

100 = (CPU Time/DB Time)*100 + (Wait Time/DB time)*100

che è il modo in cui AWR ci presenta i Top Timed Events. Vediamo. Il seguente esempio è preso da un recente tuning che ho fatto proprio su una vecchia versione 10g.

Report AWR - Versione 10.2.0.5

 

 



 

DB Time = 440 mins = 26400 secs

Nelle versioni successive, la colonna contenente la percentuale (la seconda da destra) prende esplicitamente il nome di “%DB Time”

log file switch (checkpoint incoplete) 11908 / 26400 => 0,45106 => 45,1%
gc buffer busy 5376 / 26400 => 0,20363636 => 20,4
PX Deq Credit: send blkd 1537 / 26400 => 0,058219696 => 5,8%
buffer busy waits 1358 / 26400 => 0,0514393939 => 5,1%

Nelle versioni successive, la colonna contenente la percentuale (la seconda da destra) prende esplicitamente il nome di “%DB Time

Report AWR - Versione 11.2.0.4



 



DB Time = 498 mins = 29880 secs

db file sequential read 2736 / 29880 => 0,09156 => 9,15%
db file scattered read 1753 / 29880 => 0,05866 => 5,86%
log file sync 1500 / 29880 => 0,05020 => 5,02%
row cache lock 1096 / 29880 => 0,03668 => 3,67%

Report AWR - Versione 12.1.0.2


 

 

DB Time = 21 mins = 1260 secs

db file sequential read 57,5 / 1260 => 0,04563 => 4,56%
rdbms ipc reply 50,7 / 1270 => 0,04023 => 4,02%
DFS lock handle 18,2 / 1270 => 0,01433 => 1,43%
log file sync 13,6 / 1270 => 0,01070 => 1,07%

DB Time (1 di 3) DB Time (3 di 3)

venerdì, febbraio 12, 2016

DB Time (1 di 3) (ITA)

Qui la versione Inglese

DB Time (2 di 3)
DB Time (3 di 3)

Quando abbiamo a che fare con il “tuning“ dobbiamo sempre fare i conti con il tempo. L’utilizzatore finale di un database percepisce ogni tipo di problema sotto forma di tempo di risposta. Il tempo è ciò che mette in relazione l'esperienza utente con le prestazioni del database.

Nella ormai datata versione 10g, Oracle introdusse ciò chiamò “Intelligent Infrastructure”. Lo scopo di tale infrastruttura è triplice:
- self-monitor
- self-diagnostic
- self-tuning

Questo avveniva nel 2004.

In questo documento è nei prossimi, parleremo di 2 strumenti che abbiamo a disposizione
- DB Time
- ASH

DB Time

È definito come la “somma del tempo speso all’interno del database nel processare una richiesta utente”.

È una grandezza misurata in microsecondi e la possiamo ottenere interrogando il dizionario dati. Le viste che espongono le informazioni sono:
- V$SYS_TIME_MODEL
- V$SESS_TIME_MODEL

Quando un processo non può consumare CPU, è costretto ad aspettare per poterla nuovamente impegnarla. Noi conosciamo questa attesa, come “wait event”. Detto in altre parole, quanto un processo non può utilizzare una CPU, ci avvisa dicendo che aspetterà ed il motivo dell’attesa è proprio il “wait event”.

Ma non sempre le attese hanno un impatto sulle prestazioni. In tal caso diciamo che gli eventi di attesa sono di tipo “Idle”. Quando invece l’evento di attesa influenza la risposta di uno statement diciamo che è di tipo “Non-Idle”.

Un processo attivo (che lavora) quindi o consuma CPU, oppure aspetta su un evento di tipo Non-Idle.

Tutto questo può essere espresso attraverso un’espressione matematica, nel seguente modo:

DB Time = CPU Time + Non Idle Wait Time

Quasi sempre il “Non-Idle” è sottinteso, così l’espressione diventa

DB Time = CPU Time + Wait Time

Volendo essere precisi, la relazione corretta è 

DB Time = CPU Time + Wait Time + gap

Il motivo è che quando le CPU di un sistema sono molto impegnate, aumenta il “CPU Queue Time”, ovvero il tempo di attesa che i processi impiegano prima di utilizzare una CPU. Oracle chiama questa particolare attesa,  “CPU Wait Time”, che ovviamente è una scelta piuttosto infelice come nome.

Maggiori dettagli su questa particolare tematica sono ottenibili nei link presenti nei riferimenti sotto indicati. In ogni caso, in questo articolo, siamo interessati al caso più comune:

DB Time = CPU Time + Wait Time

Riferimenti