Optimize oracle on VMware (April 2011)
Upcoming SlideShare
Loading in...5

Optimize oracle on VMware (April 2011)



Talk on optimization of Oracle databases on VMWare ESX. Oracle open world 2010

Talk on optimization of Oracle databases on VMWare ESX. Oracle open world 2010



Total Views
Views on SlideShare
Embed Views



3 Embeds 9

http://www.linkedin.com 7
http://www.techgig.com 1
https://www.linkedin.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Apologies, I’m a database type.....Quest is best known for toad, but we also have enterprise monitoring across all levels of the stackIn Melbourne, SQL Navigator + the spotlights. It’s not a complete co-incidence about the star trek theme.
  • Had a lot of fun with toad over the years
  • Insanely popular – literally millions of users
  • As well as total memory to the VM, you can:Adjust memory “shares”, which determine priority for this machine when in contention with other machinesReservation: guaranteed (sort of) amount of memory to allocate Limit, if you want to prevent VM from getting all it’s memory Memory reservationsMemory SharesIdle memory taxMemory sharingThe Balloon driver (vmmemctl) ESX swapping

Optimize oracle on VMware (April 2011) Optimize oracle on VMware (April 2011) Presentation Transcript

  • Optimize Oracle on VMware
    Guy Harrison
    Director, R&D Melbourne
  • Introductions
  • Agenda
    Motivations for Virtualization
    VMware ESX resource management:
    Paravirtualization (OVM) vs Hardware Assisted Virtualization (ESX)
  • Motivations for Virtualization
  • Resistance to Database virtualization
  • DB virtualization is happening
  • Dba-village.com
    Mar 2010
    May 2009
  • Oracle virtualization is lagging....
  • Managing ESX memory
    ESX can “overcommit” memory
    Sum of all VM physical memory allocations > actual ESX physical memory
    Memory is critical to Oracle server performance
    SGA memory to reduce datafile IO
    PGA memory to reduce sort & hash IO
    ESX uses four methods to share memory:
    Memory Page Sharing
    ESX swapping
    Memory compression
    DBA needs to carefully configure to avoid disaster
  • Configuring VM memory
    VMs Compete for memory in this range
    Relative Memory Priority for this VM
    Maximum memory for the VM (dynamic)
    Minimum Memory for this VM
  • Monitoring VM memory
  • ESX and VM memory
    ESX Swap
    ESX swap
    ESX virtual memory
    Effective VM physical memory
    ESX physical memory
    VM virtual memory
  • ESX Ballooning
    ESX Swap
    ESX swap
    ESX virtual memory
    Apparent VM physical memory
    Effective VM physical memory
    ESX physical memory
    VM Swap
    VM Swap
  • ESX Ballooning
    As memory grows, ESX balloon driver (vmmemctl) forces VM to page out memory to VM swapfile
  • ESX Ballooning
    Inside the VM, paging to the swapfile is observed.
    The guest OS will determine which pages are paged out
    If LOCK_SGA=TRUE, then the SGA should not be paged.
  • ESX Swapping
    ESX Swap
    ESX swap
    ESX virtual memory
    Effective VM physical memory
    ESX physical memory
    VM virtual memory
  • ESX Swapping
    ESX Swap
    ESX swap
    Apparent VM physical memory
    Effective VM physical memory
    ESX virtual memory
    ESX physical memory
  • ESX Swapping
    ESX swaps out VM memory to ESXswapfile
  • ESX Swapping
    Within the VM, swapping cannot be detected.
    ESX will determine which memory pages go to disk
    Particularly occurs when VMware tools are not installed
    Even if LOCK_SGA=TRUE, SGA memory might be on disk
  • Avoiding Ballooning and swapping
    memory reservations help avoid ballooning or ESX swapping
  • Other VMware memory management thoughts
    Memory page sharing
    Multiple VMs can share an identical page of memory (Oracle code pages, etc)
    Modern chipsets reduce memory management overhead
    Multiple hardware page layers
    Memory compression (new in ESX 4.1)
    Pages are compressed and written to cache rather than to disk
    Swapping is more expensive than ballooning
    Slower to restore memory
    OS and Oracle get no choice about what gets paged
    “Double paging” can occur – guest and ESX both page a block of memory
  • Ballooning vs. Swapping
    Swingbench workload running on Oracle database – from VMWare whitepaper: http://www.vmware.com/files/pdf/perf-vsphere-memory_management.pdf
  • VMware memory recommendations
    Paging or swapping of PGA or SGA is almost always a Very Bad Thingtm.
    Use memory reservations to avoid swapping
    Install VMware tools to minimize swapping
    Ballooning >> swapping (double paging, paging SGA, high swap-in latency, etc)
    Set Memory reservation = PGA+SGA+process Overhead
    Be realistic about memory requirements:
    In physical machines, we are used to using all available memory
    In VM, use only the memory you need, freeing up memory for other VMs
    Oracle advisories (or Spotlight) can show you how much memory is needed
    Reduce VM reservation and Oracle memory targets in tandem to release memory
  • VMware CPU management
    If more virtual CPUs than ESX CPUs, then VCPUs must sometimes wait.
    Time “stops” inside the VM when this occurs
    For multi-CPU VMs, it’s (nearly) all or nothing).
    A VCPU can be in one of three states:
    Associated with an ESX CPU but idle
    Associated with an ESX CPU and executing instructions
    Waiting for ESX CPU to become available
    Shares and reservations determine which VM wins access to the ESX CPUs
  • Configuring VM CPU
    VMs compete for CPU in this range
    Shares determine relative CPU allocated when competing
  • CPU utilization VM
    “CPU Ready” is the amount of time VM spends waiting on ESX for CPU
    Inside the VM, CPU stats can be misleading
  • SMP for vCPUs
    ESX usually has to schedule all vCPUs for a VM simultaneously
    The more CPUs the harder this is
    Some CPU is also needed for ESX
    More is therefore not always better
    (Thanks to Carl Bradshaw for letting me reprint this diagram from his Oracle on VMWare whitepaper)
  • ESX CPU performance comparisons
    VT enabled
    Vs 2 core 1.8 GHz physical machine
  • Programmatic performance
  • Programmatic performance (2)
  • ESX CPU recommendations
    Use up to date chipsets and ESX software
    Allocate as few VCPUs as possible to each VM
    Use reservations and shares to prioritise access to ESX CPU
    Performance of CPU critical workloads may be disappointing on older hardware
    Monitor ESX Ready time to determine the “penalty” of competing with other virtual machines
  • Typical VMWare disk configuration
  • Disk Resource Allocation
    Disk shares can be used to prioritize IO bandwidth.
    However, ESX often does not know underlying storage architecture
  • Performant VMware disk configuration
  • Optimal configuration
    See “Oracle Database Scalability in VMware® ESX” at www.vmware.com/oracle
    Each virtual disk directly mapped via RDM to dedicated RAID 0 (+1) group
    41 Spindles!
  • VMWare disk configuration
    Follow normal best practice for physical disks
    Avoid sharing disk workloads
    Dedicated datastores using VMFS
    Align virtual disks to physical disks?
    Consider Raw Device Mapping (RDM)
    If you can’t optimize IO, avoid IO:
    Tune, tune, tune SQL
    Prefer indexed paths
    Memory configuration
    Don’t forget about temp IO (sorts, hash joins)
  • Paravirtualizationvs “Hardware Virtualization”
    Virtualization is not emulation....
    Where-ever possible, Hypervisor runs native code from OS against underlying hardware
    Because a virtualized operating system is running outside privileged x86 “ring 0”, direct calls to hardware need special handling.
    The three main approaches are:
    Full Virtualization (VMWare on older hardware)
    ParaVirtualization (Xen, Oracle VM)
    Hardware Assisted Virtualization (Intel VT, AMD-V)
  • Full virtualization
    Hardware calls from the Guest are handled by the hypervisor by:
    Catching the calls as they occur at run time
    Re-writing the VM image at load time (binary translation)
    Requires no special hardware
    Supports any guest OS
    Relatively Poor performance
    Used by ESX on older chip-sets
    Guest OS
    Ring 0
  • Hardware Assisted virtualization
    Intel VT and AMD-V chips add a “root mode”.
    Guest can issue instructions from non-root Ring 0.
    CPU can divert these to hypervisor
    No changes to OS required
    Good performance
    Requires modern chipsets
    Root Mode
    Non-Root Mode
    Ring 0
  • Paravirtualization
    • Guest operating system is rewritten to translate device calls to “hypercalls”
    • Hypercalls are handled by a special VM (dom0 in Xen/OVM)
    • Good performance but requires modified guest OS
    • Xen can use either paravirtualization or hardware assist
    Ring 0
  • Paravirtualization and RAC
    According to Oracle, only a paravirtualization solution can guarantee clock-synchronization between members of a RAC cluster.
    For this reason, RAC is not officially supported on VMWare, but is on Xen based OVM
    Single instance databases are fully supported – but not certified – on ESX.
    See Oracle MySupport Note 249212.1
  • References
    My blog (www.guyharrison.net ):
  • End of Presentation