cpuinfo, bogomips and duo core

[Reindl Harald]

Am 12.02.2013 11:01, schrieb Gordan Bobic:
> On 12/02/2013 00:42, Reindl Harald wrote:
>> under real load the XEON is so much faster even
>> with the virualization overhead which is small
>> these days but still exists
> 
> Small as in un-noticeable if your VMs are largely idling. Not that small if you intend to push the hardware to it's
> actual limits. On a Core2 class machine, the best hypervisors manage to do it with about a 25% performance drop.
> Many do worse.
> 
> http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

there is never 25% performance drop in case of CPU

this may be true for IO and even this depends heavily on the
storage, a dedicated SAN storage with 1 GB writeback cache
will outperform in most cases you local disks because finally
you invest much more money and disks in a shared spindle
and the dimension is for your whole infrastructure while
most guests are not the whole day busy, the same for CPU

means:
you buy much better hardware with more and faster CPU's
for a single device as you would buy for 20 machines
and most of the day one or two guests can allocate
most of the ressources on their own

>> i have seen the XEON machine with a Load of 140 while a massive DDOS was running
>> with ten thousands of connections and 100Mbit incoming traffic from always the
>> same request on a mysql-driven website and ssh/lsof/ps aux was as fast as it would
>> be idle, on the home-machine with a load over 40 you are done
> 
> It's not that clear cut - it depends on where the DOS bottlenecks the system. If you have a web server being DOS-ed
> and it's waiting for responses from MySQL which is on a different server, then yes, you'll have a very high load
> and very low CPU usage since most of the httpds are waiting for a response from the DB. Since CPU usage is low, the
> machine itself will be very responsive if you ssh into it. The web response, may well not be.

it is a clear cut

the DB was on the same VM
the VM had as much virtual CPU's as the host
both, the host and the VM had 100% CPU load

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20130212/7354424a/attachment.sig>