Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

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.

Find more posts tagged with

Accepted answers

All comments

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).

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

infosat

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.

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.

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!

infosat

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.