What ration of virtual to real CPU should I have for quiet, but big spike VMs

[yatesco]

Hi,

short version - if I have N boxes, what is X where X is the number of light weight virtual CPUs before performance drops off? Is X N? 2N etc.? For example, if I have 8 cores, should I only assign 6 of them to virtual machines, or can I assign 8, or 12 or what? I am not looking for theoretical ideas, more real life.

longer version -

I need to run two different groups of virtual machines - one pool is made up of 10 little Linux machines (at the moment they are KVM, but maybe they should be OpenVZ) which run things like my build server, my source control, bug tracker etc. They are used by 6 people occasionally throughout the working week.

The other group is 6 windows boxes which have all worked perfectly fine with a single CPU and 1 or 2GB RAM. These machines will either be doing absolutely nothing or they will be quite busy. It is highly unlikely there will be more than one or two busy at the same time.

For context, all of these machines are running on a single Dell PE2950 (8 cores), 16GB RAM and I can hear the snores coming from the server from here. It really isn't bothered at all.

Hope that is clear.

Col

 

[dietmar]

I do not understand that question. If you have 8 cores performance is limited by 8 cores.

 

[yatesco]

Hi dietmar,

(We seem to be playing forum ping pong )

Let me rephrase the question - I have 6 virtual machines, each with 2 CPUs each - so 12 total CPUs. Most of the time each guest is using between 0 and 1% of its CPU.

Is there any reason I cannot run all those virtual machines on a single box with 4 physical cores? How many would you run on a single box? 2 (so there is one physical core to each virtual core)?

I am just looking for some advice/pointers really

Thanks,

Col

 

[dietmar]

Let me rephrase the question - I have 6 virtual machines, each with 2 CPUs each - so 12 total CPUs. Most of the time each guest is using between 0 and 1% of its CPU.

Is there any reason I cannot run all those virtual machines on a single box with 4 physical cores?

No.

How many would you run on a single box? 2 (so there is one physical core to each virtual core)?

If you run more VMs you get less performance per VM. It is usually no problem to run 10 to 20 KVM VM on such host.

 

[yatesco]

Excellent - this confirmed my recent experiments, but I just wanted to check with the experts.

Many thanks!

(other suggestions/comments/real world feedback are of course welcome!)

 

[dietmar]

Btw, density with openvz VMs is usually higher.

 

[JustaGuy]

all of these machines are running on a single Dell PE2950 (8 cores), 16GB RAM and I can hear the snores coming from the server from here. It really isn't bothered at all.

LOL @ yatesco.
My 2950 heats the place, I'll need to find it something to crunch on over the winter- It's too bad I can't rent out a few vps'.

I have some in the same position, I figure many do who make use of virtualization. That's the principle that allows server consolidation to work.
I chose Proxmox in part because I ran into vCPU limits on other platforms, some VMs are equipped with more access to CPU than they'll use 80% of the time.

Since 20% of the time they're not allowed to bog down, those extra vCPU allocations become key.

I've wondered whether there's any performance difference in adding 1 core/socket in order for the guest to make use of the additional virtualized L2 cache.
No time to research & benchmark so far, but it's on the to-do list.

If anyone has an idea of the inner workings and ramifications of such a theory, I'd be glad to benefit from your knowledge before I embark on such testing.

 

[JustaGuy]

As an update to my last post, FWIW I found some interesting material for the case of packet routing from the Vyatta forums.

Regarding their interface affinity automation:

The algorithm is to assign the same tx and rx queues of all NICs to the same CPU. For example tx0 of eth0, rx0 of eth0, tx0 of eth1, rx0 of eth1, etc. are all assigned to CPU 0. This ensures that processing of a packet stays on the same CPU from receive processing through to transmit processing no matter what NIC it is received or transmitted on. This avoids cache thrashing, which makes a huge difference in performance.