Analisi di performance con Oracle su virtual machine

Presentazione sul tema: "Analisi di performance con Oracle su virtual machine"— Transcript della presentazione:

1 Analisi di performance con Oracle su virtual machine
Gianluca Peco 1

2 Sommario Architetture e layout Baseline Descrizione dei test
Efficienza e scalabilita’ Test del grado di parallelismo delle CPU Test del grado di parallelismo nell’accesso alla memoria Pattern di accesso ai database realistico SELECT only ( NetIO ) Pattern di accesso ai database realistico OLTP ( Disk I/O)‏ Timekeeping Sincronizzazione dell’orologio di sistema da una corretta fonte di clock Controllare il sommario con le slide 2

3 Architetture di VM

4 Layout del testbed wn-01-03-01-09-a
Le quattro macchine virtuali sono tutte biprocessore OS SL5.0 8 GB RAM Intel(R) Xeon(R) CPU @ 2.00GHz kernel xen_3.1.0 SMP 2 GB di RAM wn a OS RHEL4U4 kernel ELsmp Le macchine reali sono quadriprocessore kernel el5PAE SMP

5 Baseline di rete e GPFS Trasmissione e ricezione verso/da macchina reale esterna utilizzando netperf UDP Spiegare bene i test di rete e il test di GPFS I throughput aggregati del file system GPFS sono al netto dei dati trasferiti 5

6 Test di accesso alla memoria e cpu
Programma scritto in C che alloca,scrive e legge ciclicamente 256 MB di memoria Programma di simulazione Gauss v30r4, generazione e simulazione Geant4 di eventi bb con decadimenti inclusivi ad utilizzo intensivo di cpu 6

7 Descrizione dei Test Oracle (1/2)‏
Test semplici: viene “stressato” un particolare aspetto del sistema Parallel: misura il grado di parallelismo nel calcolo parallelo. Efficienza e scalabilita’ nel calcolo su interi. Oracle Parallel Query: script SQL che lancia un comando SQL parallelo su una tabella partizionata Parallelismo interno: i thread sono creati internamente da Oracle Test CPU bound. Memory: misura il grado di parallelismo nell’accesso alla memoria. Efficienza e scalabilita’ nella contesa alla memoria. Test standard JLOCI: un comando SQL ricorsivo, mirato a determinare quante LIO (Logical I/O Operation) e’ in grado di effettuare una CPU ( . Parallelismo esterno: piu’ test script lanciati in backgorund da shell. I thread sono creati dal sistema operativo Test Memory bound: vengono effettuate piu’ select parallele che accedono agli stessi dati in memoria. Jloci.sql SQL statement that is basically CPU bound and gives a good indication on how many LIO a certain CPU can do – Single session-multisession LIO: logical IO operation: An operation in which the Oracle kernel obtains and processes the content of an Oracle block from the Oracle database buffer cache. The code path for an Oracle LIO includes instructions to determine whether the desired block exists in the buffer cache, to update internal data structures such as a buffer cache hash chain and an LRU chain, to pin the block, and to decompose and filter the content of the retrieved block. Oracle LIO operations occur in two modes: consistent and current. In consistent mode, a block may be copied (or cloned) and the clone modified to represent the block at a given point in history. In current mode, a block is simply obtained from the cache “as-is. 7

8 Descrizione dei Test Oracle (2/2)‏
Test realistici: tramite SwingBench vengono simulate operazioni complesse sul database. OLTP (Online Transaction Processing): simula applicazioni transaction oriented (es. FTS, CASTOR) in cui vengono effettuate soprattutto piccole transazioni (operazioni di lettura/scrittura) che modificano piccole quantita’ di dati. Basato sul pattern OrderEntry con thinking time=0 Tablespace 100 MByte ( tutto in memoria ) per ridurre al minimo l’I/O su disco ( praticamente solo i REDOLOG) ca 8Mb/s e accesso praticamente sequenziale in scrittura Praticamente no Net I/O ca 4 Mb/s R/W Rapporto letture/scritture 60/40 Select only: simula applicazioni data warehouse (es. Conditions Database) in cui vengono effettuate soprattutto query (operazioni di sola lettura) su grandi moli di dati e pochi update Tablespace 100 MByte ( tutto in memoria ) effettuando SELECT Disk I/O ca 0 Net I/O nelle condizioni peggiori 50 Mb/s Rapporto Letture/scritture 100/0

9 Efficienza Memoria & CPU
I test di accesso alla memoria eseguito sequenzialmente con 1,2,3,4,8 processi presenta un notevole grado di efficienza rispetto alla macchina reale Il numero di parallel clients in ascisse rappresenta il totale dei processi contemporaneamente in esecuzione in una macchina fisica I test realizzati con Parallel.sql e grado di parallelismo 1,2,3,4,8 dimostra efficienze notevoli sia con singola che doppia vm confermando i risultati ottenuti con i test della baseline Il Dom0 si comporta essenzialmente come la macchina reale 9

10 Efficienza OLTP & SELECT ONLY
I test effettuati utilizzando un pattern realistico SELECT ONLY evidenziano che in condizioni miste con prevalenza di network I/O : l’efficienza cala a meno del 50% che XEN tende a comportarsi leggermente peggio di VMware I test effettuati utilizzando un pattern realistico OLTP dimostra che in condizioni miste di cpu utilization, memory utilization , disk I/O sequenziale e random (con I/O wait < 10%): l’efficienza cala a ca il 75% XEN tende a comportarsi leggermente peggio di VMware 10

11 Scalabiltà cpu & memory
Nel primo test Parallel.sql Il sistema scala linermente fino a 4 processi sia nel dom0 che nella doppia vm e fino a 2 processi nella macchina virtuale singola Nel test memory.sql multi trhead Il sistema non scala perfettamente evidenziando qualche problema probabilmente nell’accesso contemporaneo alla memoria da parte dei singoli core Non si notano differenze sostanziali tra reale e virtuale 11

12 Scalabilita’ Select only
Backpressure del load generator costante e non bloccante. Cpu idle del load generator > 50% Numero di TPS in funzione del numero di client del load generator in tutte le condizioni e relativa percentuale di cpu idle ( media delle due nel caso di doppia ) Pare che Vmware necessiti di meno risorse rispetto a XEN 12

13 Scalabilita’ OLTP Backpressure del load generator costante cpu idle > 50% Numero di TPS in funzione del numero di client del load generator in tutte le condizioni e relativa percentuale di cpu idle misurato dai virtual host Pare che Vmware necessiti di meno risorse rispetto a XEN 13

14 Timekeeping Timekeeping considerazioni generali
Il problema riguarda la sincronizzazione dell’orologio hw in condizioni di utilizzo intenso delle risorse ( CPU,IRQ ) il sistema perde dei tick che il kernel ospitato non riesce a recuperare. Da cio’ si ottiene una deriva dell’orologio sw in piu’ o in meno non ‘gestibile da ntpd Workaround XEN – Nella versione da noi provata abbiamo impostato il parametro del kernel clock=PIT Workaround VMWARE -Installazione dei vmware-tools che implementano correzioni a livello applicazione. Hanno un comportamento anomalo e precisamente si attivano solo in condizioni di alto utilizzo delle risorse creando una gestione ad elastico del tempo. ( parametrizzabile )Potrebbero influenzare il comportamento delle applicazioni che fanno richieste all’orologio di sistema come i benchmark stessi 14

15 Conclusioni In linea generale i sistemi virtuali testati si dimostrano robusti ed affidabili in tutte le loro componenti e con entrambi i sistemi di virtualizzazione Le performance in presenza di notevole contesa delle risorse evidenziano efficienze di : CPU 85-95% Memory 85-95% Cpu Disk I/O 60-80% ( GPFS )‏ CPU Net I/O 50% Ambiti di utilizzo di Oracle on VM : Ambiente di test e sviluppo Aggregazione di istanze a basso utilizzo di CPU in sistemi multiprocessore con alto grado di isolamento Sistemi di HA senza l’utilizzo di Oracle RAC 15

16 TO DO FAILOVER e HA RAC ORACLEVM ( Freeware )
Test di scalabilita’ ed efficienza in condizioni di utilizzo normale delle risorse Fine tuning dei sistemi di virtualizzazione per ambienti applicativi ‏specifici Realizzazione di immagini di applicazioni preconfezionate (Oracle,Mysql,Cluster,etc.) 16

17

18 Test simili Nota vmware A performance comparison
Nota XenSource A performance comparison Nota Vmware SQL Server performance Nota Vmware Multi-NIC 18