ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    ESXi VM virtual sockets / cores best practice

    Scheduled Pinned Locked Moved IT Discussion
    5 Posts 2 Posters 850 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      Carnival Boy
      last edited by

      OK, I've done some Googling but can't seem to find a simple, definitive answer to something that I should probably know already. I'd be grateful if you could explain this in very simple terms:

      I have a Proliant DL380 G9 with 2 Intel Xeon CPUs installed and 96GB RAM. This is running a small handful of VMs. So:
      Processor Sockets: 2
      Cores per Socket: 6
      Logical Processors: 24

      The most intensive VM is SQL Server, which I have configured with 48GB memory. My question is what should I set for "Number of virtual sockets" and "Number of cores per socket"?

      I think I've read somewhere that it doesn't make any difference and that ESXi (we're running 5.5) will handle all this at the backend and that this only needs setting to meet licencing restrictions. But I've read elsewhere long technical discussions on what it means for performance, most of which I don't understand.

      Can some explain, in simple terms, what the implications of setting virtual sockets and cores for a VM is, and what is a good rule of thumb for SQL Server? At the moment I've set them both to 1.

      scottalanmillerS 2 Replies Last reply Reply Quote 0
      • scottalanmillerS
        scottalanmiller @Carnival Boy
        last edited by

        @Carnival-Boy said:

        The most intensive VM is SQL Server, which I have configured with 48GB memory. My question is what should I set for "Number of virtual sockets" and "Number of cores per socket"?

        Makes no difference at all. The two choices exist purely for passing geometric chip configuration on to the OS in case there are licensing concerns (like Windows 2012 will install on two CPUs with twenty four cores each, but not on twenty four CPUs with two cores each.) Each core is discrete at this level and how they are defined makes no technical difference.

        1 Reply Last reply Reply Quote 1
        • scottalanmillerS
          scottalanmiller @Carnival Boy
          last edited by

          @Carnival-Boy said:

          Can some explain, in simple terms, what the implications of setting virtual sockets and cores for a VM is, and what is a good rule of thumb for SQL Server? At the moment I've set them both to 1.

          I always just use the core count and never the CPU count. No need to tell the VM that there are multiple CPUs, especially since it is generally all on one anyway for NUMA performance reasons.

          1 Reply Last reply Reply Quote 1
          • C
            Carnival Boy
            last edited by

            So what should I set for cores? 1? 2? More than 2?

            scottalanmillerS 1 Reply Last reply Reply Quote 0
            • scottalanmillerS
              scottalanmiller @Carnival Boy
              last edited by

              @Carnival-Boy said:

              So what should I set for cores? 1? 2? More than 2?

              Now that gets out of the area of "easy to answer." LOL This comes down to your workload. The rule of thumb is start with one, test, increase, test and repeat. Stop when you start to lose performance and go back to the one that was best.

              Not all that helpful, is it?

              For a SQL Server, I'm pretty confident that the right answer is not "one". I would start with two and see how it performs. Chances are two is going to be the minimum that you would consider using. Watch those two and see how they are utilized. If load gets high (that's load factor... the run queue length) then more vCPU might be in order. Not super common (by VM count) to go over four vCPU, but there are certainly cases for it.

              1 Reply Last reply Reply Quote 1
              • 1 / 1
              • First post
                Last post