ESXi

 View Only

  • 1.  oracle VM, 32 CPUs needed - sockets & core per socket setting

    Posted Jun 29, 2015 05:14 AM

    Hi,

    I need to setup a oracle vm. my Hypervisor  has 2 socket & 8 core.

    Oracle looks at # of cores no matter what. (as far as i know )

    What would be ideal setting i can present the vm with # of socket & # of cores per socket ?

    My understanding is i should select 1 socket & give 32 cores per socket for better NUMA.

    thanks.



  • 2.  RE: oracle VM, 32 CPUs needed - sockets & core per socket setting
    Best Answer

    Broadcom Employee
    Posted Jun 29, 2015 05:26 AM

    By default you would want to give it 32 sockets 1 core a socket. This will allow the ESXi host to expose the underlying NUMA to the guest

    But your host is only 16 cores why would you want to assign 32? I know you most likely have hyperthreading but assigning 32 will tell the VM it has 32 "full" cores and you may find performance is not all that good.



  • 3.  RE: oracle VM, 32 CPUs needed - sockets & core per socket setting

    Posted Jun 29, 2015 06:45 AM

    thanks, similar things i heard from When to Overcommit vCPU:pCPU for Monster VMs | VMware vSphere Blog - VMware Blogs

    But then what should be solution here ? at the end dba needs 32 CPUs.

    Either i can buy new host with 4 sockets  & 8 cores each ( or 2 socket 16 core per socket etc) or

    tell him i can give only 16 Cores, unless u get me new Hypervisor  with 32 sockets  or

    i can utilize the hyper threading

    What would to practical solution ?



  • 4.  RE: oracle VM, 32 CPUs needed - sockets & core per socket setting

    Broadcom Employee
    Posted Jun 29, 2015 10:16 AM

    Yeah ok that's a tricky one if you need 32 cpus but the host only has 16 actual processors.

    I guess at the end of the day its going to depend on how the Database is going to be used, the only real time it will cause issues is if the VM tries to use more than 16 vCPUs at or near 100%.

    If you go down the route of assigning 32, you may be better off using the PreferHT=true setting at least this will give a cleaner vNUMA to the guest and does generally preform better when over committing like this.

    Yeah I think your on the right path, give the client the option, say on the host you have you can give it 32 vCPUs but you will only get 16 cores worth of performance and could lead to performance problems down the track etc etc,

    You can also create it now with 32 and later down the track move it onto a larger host....

    Cheers