Gianluca Peco Barbara Martelli ORACLE on VM benchmark · Utilizzo virtual machines con Oracle (funzionalita', performance) Gianluca Peco Barbara Martelli

Summary Setup Timekeeping Efficienza e scalabilita’ Il problema di mantenere sincronizzato l’orologio di sistema e di una corretta fonte di clock . Vedi note VMWARE,Microsoft,XEN 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) Possibilita’ di utilizzo di ORACLE on VM in LHC Conclusioni

Descrizione dei Test (1/2) Test semplici: viene stressato un particolare aspetto del testbed 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 (http://www.miraclebenelux.nl/jloci.html) . 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 http://www.miraclebenelux.nl/jloci.html 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.

Descrizione dei Test (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 100MB ( tutto in memoria ) per ridurre al minimo l’I/O su disco ( praticamente solo i REDOLOG) ca 1MB/s e accesso praticamente sequenziale in scrittura Praticamente no Net I/O ca 500KB/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 100MB ( tutto in memoria ) effettuando SELECT Disk I/O ca 0 Net I/O nelle condizioni peggiori 7MB/s Rapporto Letture/scritture 100/0

Timekeeping Timekeeping considerazioni generali Il problema riguarda la sincronizzazione dell’orologio hw in condizioni di utilizzo pesante delle risorse ( CPU,IRQ ) il sistema si 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 . E’ possibile che in kernel piu’ recenti possa essere stata risolta? Workaround VMWARE -Installazione dei vmwaretools che risolvono a livello di servizio.Hanno un comportamento anomalo come gia’ verificato da Vincenzo e precisamente si attivano principalmente in condizioni di alto utilizzo delle risorse creando una gestione ad elastico del tempo. Potrebbero influenzare il comportamento delle applicazioni che fanno richieste all’orologio di sistema p.e. i benchmark stessi http://www.vmware.com/pdf/vmware_timekeeping.pdf http://support.microsoft.com/kb/918461 http://lists.centos.org/pipermail/centos/2008-January/092410.html

Efficienza Memory & CPU I test utilizzando Memory test creato per verificare colli di bottiglia nell’accesso alla memoria eseguito sequenzialmente con 1,2,3,4,8 processi presenta un notevole grado di efficienza rispetto alla macchina reale I test realizzati con Parallel test e grado di parallelismo 1,2,3,4,8 dimostra effcienze notevoli sia con singola che doppia vm confermando i risultati ottenuti con i test realizzati da programmi di ricostruzione. Il Dom0 si comporta essenzialmente come la macchina reale

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

Scalabiltà La scalabilita’ rimane costante Nel primo test Parallel.sql Fino al quarto grado (4cpu) sia Nell’ospitante puro che nella Doppia vm in contemporanea Nel test memory.sql multisession La scalabilita’ e’ quasi costante Evidenziando qualche problema Nell’accesso contemporaneo alla Memoria da parte dei core Non ci sono differenze sostanziali Tra reale e virtuali

Scalabilita’ Select only Backpressure del load generator costante e non bloccante. 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 ) misurato dai virtual host normalizzato al 100% Pare che Vmware necessiti di meno risorse rispetto a XEN

OLTP Backpressure del load generator costante e non bloccante. 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 normalizzato al 100% Pare che Vmware necessiti di meno risorse rispetto a XEN

Test simili effettuati dai produttori Nota vmware A performance comparison Nota XenSource A performance comparison http://blogs.xensource.com/simon/wp-content/uploads/2007/03/hypervisor_performance_comparison_1_0_3_no_esx-data.pdf Nota Vmware SQL Server performance Nota Vmware Multi-NIC

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 : Ambiente di test e sviluppo Aggregazione di Istanze a basso utilizzo di CPU in sistemi multiprocessore ( P.e. LFC ) in sistemi con alto grado di isolation

TO DO FAILOVER e HA RAC ORACLEVM Test di sclabilita’ in condizioni di basso utilizzo di CPU ( Disk I/O , Net I/O, CSW, IRQ , etc )