3

I'm evaluating a private cloud solution built on kvm and so far I'm not getting the speed of the system that I need for my purposes.

According to the vendor the underlying machines should be equipped with "state of the art" E5-4620 processors.

However, /proc/cpuinfo tells me that they are something rather different:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel Xeon E312xx (Sandy Bridge)
stepping        : 1
microcode       : 1
cpu MHz         : 2199.998
cache size      : 4096 KB

E3-12xx Sandy Bridge is something like 5 years old and could be an explanation why my current bare metal servers from the same era of processors actually are faster.

However, this being a virtual environment - something that's new to me - I'm unsure if I can trust it 100%.

Same info from dmesg:

$ dmesg | grep -i intel
  Intel GenuineIntel
CPU0: Intel Xeon E312xx (Sandy Bridge) stepping 01

However, dmidecode says something completely different:

# dmidecode 2.12
SMBIOS 2.8 present.

Handle 0x0400, DMI type 4, 42 bytes
Processor Information
        Socket Designation: CPU 0
        Type: Central Processor
        Family: Other
        Manufacturer: Red Hat
        ID: A1 06 02 00 FF FB 8B 0F
        Version: RHEL 7.2.0 PC (i440FX + PIIX, 1996)
        Voltage: Unknown
        External Clock: Unknown
        Max Speed: 2000 MHz
        Current Speed: 2000 MHz
        Status: Populated, Enabled
        Upgrade: Other
        L1 Cache Handle: Not Provided
        L2 Cache Handle: Not Provided
        L3 Cache Handle: Not Provided
        Serial Number: Not Specified
        Asset Tag: Not Specified
        Part Number: Not Specified
        Core Count: 1
        Core Enabled: 1
        Thread Count: 1
        Characteristics: None

I assume (hope/guess) the i440FX is more like what platform was used to build the kernel or similar rather than being an actual chip being in use...

If the underlying hardware indeed is new and equipped with fast CPUs there's something else that's wrong and I will need to investigate that. If not I need to ask the vendor:

  1. Why are you trying to mislead me.

  2. can you move my VM to a faster machine.

Any input appreciated.

Jensd
  • 133
  • 1
  • 5
  • 1
    If you have no access to the hypervisor, debugging performance will be almost impossible. You need to work with the provider to resolve this – dyasny Oct 12 '16 at 14:15
  • @dyasny I am! Since this is an evaluation of a possible environment to move into they are eager to help. Not getting the performance we need is a deal breaker... – Jensd Oct 12 '16 at 14:17
  • If you could provide some details, maybe in a new question, we could throw in some ideas as to where to look for bottlenecks. Stuff like the hardware and distro and versions used on the hypervisors, actual VM settings from the hypervisor POV, what runs inside the VM, how you measure and expect to see the performance, what the intended workload is... Anything else that is relevant of course – dyasny Oct 12 '16 at 14:23

1 Answers1

6

Your VM is running on top of QEMU (KVM), and reporting the CPU and chipset emulated by QEMU. The CPU you see in /proc/cpuinfo is one of the available emulation settings, see target-i386/cpu.c in the source code and the output of qemu-system-x86_64 -cpu help; it doesn't correspond to the underlying CPU (which would report a specific model, not "E312xx"). The chipset reported by dmidecode is the chipset emulated for PCI-based systems, as described in the documentation.

So none of this is evidence of your vendor misleading you.

Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • Thanks, I don't actually think they are misleading me since we already have a well established relation and have had so for several years. Something however is making this environment too slow and this was one possibility. The problems seems to be CPU-related since my testing so far reveals no io-problems. – Jensd Oct 12 '16 at 09:28