7 Replies Latest reply on Sep 15, 2010 4:01 PM by jspanitz

    Orion Server installation vCPU's

      Is there a whitepaper or guidance on running Orion NPM and APM as a VM. we are looking for what performance gains will be achieved(If any) by running multiple vCPU's. I understand that Orion is multi-threaded and would therefore gain some performance increase from multiple vCPU's, but i'm looking for some hard numbers.

        • Re: Orion Server installation vCPU's
          byrona

          I would find this information useful as well.  Currently our Orion pollers are each assigned 1 vCPU and the two pollers share a resource reserve of 2Ghz with an unlimited expandability and things seem to be running fairly well; however I have wondered if providing additional vCPU's would help.

          I know that with VMWare you can get into trouble by providing more vCPU's because the system has to wait until the total number of vCPU's allocated are available before it can send info to the processor and this can cause a resource contention (one CPU is available a lot more of the time than 4 are available).

            • Re: Orion Server installation vCPU's
              jspanitz

              byron, vmware vcpu scheduling issue was for all intents and purposes eliminated 4.0 and further improved in 4.1

              4.0 Info - http://www.vmware.com/files/pdf/perf-vsphere-cpu_scheduler.pdf

              4.1 Info - http://www.vmware.com/files/pdf/techpaper/VMW_vSphere41_cpu_schedule_ESX.pdf 

                • Re: Orion Server installation vCPU's

                  Neither of these prevent the need for 2 cores to be available at the same time to service a 2vcpu system or 4 cores to service a 4vcpu system. That is where the most performance issues come from as that need increases the cpu ready time on the vm.

                    • Re: Orion Server installation vCPU's
                      jspanitz

                      Not sure I follow.   In ESX 3.x, if you allocated 2 vcpus, ESX had to have two cores open in order to process the request, regardless of whether both vcpus were waiting.  In ESX 4.x, this is not the case.  If you have a 2 vcpu system and it asks esx to execute on just one of those vcpus it can do so without waiting for 2 cores to be free.  Of course it's not that simple and if the app truely needs all vcpus then you may run into issues.

                      "Relaxed co-scheduling introduced in ESX 4 signifcantly mitigated the CPU fragmentation problem. While the basic mechanism of
                      detecting the skew remains unchanged, the way to limit the skew has been relaxed. When a virtual machine is co-stopped, it used to be required to schedule all sibling-vCPUs simultaneously. This is too restrictive 
                      considering that not all vCPUs lagged behind. Instead, only the vCPUs that accrued enough skew will be required to run 
                      simultaneously. This lowers the number of required pCPUs for the virtual machine to co-start and increases CPU utilization. 
                      Note that it still attempts to schedule all sibling vCPUs for better performance"

                      Now if you are talking about having a 2 vcpu system on a server with 2 or fewer cores, I can see your concern.

                    • Re: Orion Server installation vCPU's
                      byrona


                      byron, vmware vcpu scheduling issue was for all intents and purposes eliminated 4.0 and further improved in 4.1

                      4.0 Info - http://www.vmware.com/files/pdf/perf-vsphere-cpu_scheduler.pdf

                      4.1 Info - http://www.vmware.com/files/pdf/techpaper/VMW_vSphere41_cpu_schedule_ESX.pdf 

                       

                       



                      Thanks for this info, I am glad to see that this was corrected!

                        • Re: Orion Server installation vCPU's

                          The way I understand it, if you have a host with 2 quad core processors running 15 VM's   14 of which have 1vcpu and 1 has 2vcpu's the machine with 2 vcpu's has to wait till there are 2 cores available at the same time before it can do anything. In esx 3.5 and 4.0 these 2 cores had to be available on the same physical cpu. in 4.1 the 2 cores can be available on either physical cpu.   but performance of your 2 vcpu machine is still impacted from this wait time. 

                            • Re: Orion Server installation vCPU's
                              jspanitz

                              infosat - again I could be wrong here, but I believe your assumption were right before esx 3.x.  Since then that is not the case.  The old method was "Strict Coscheduling".  The doc below describes the situation exactly as you laid it out.

                              http://communities.vmware.com/docs/DOC-4960

                              More on this here :

                              http://communities.vmware.com/docs/DOC-5501

                              "Back in the days of ESX Server 2.5, SMP VMs had to have their vCPUs co-scheduled at the same instant to begin running. Because only 2-way VMs were supported at this time, that meant that two CPU cores had to be available simultaneously to launch a 2-way VM. On a server with a total of only two cores, this meant that the VM could not be launched concurrently with any other process on the server. This would include the service console, the web interface, or any other process.

                              This requirement was reduced in ESX Server 3.0 through a process called relaxed co-scheduling. Effectively SMP VMs can have their vCPUs scheduled at slightly different times and idle vCPUs didn't necessarily have to be scheduled concurrently with running vCPUs. More details on this are available in the Co-scheduling SMP VMs in VMware ESX Server page. "

                               

                              Let me also say I'm not advocating allocating 4 vcpus unless it is needed.  I'd like the official numbers / recommendation from Solarwinds too.