No announcement yet.

Serious vCPU performance concern

  • Filter
  • Time
  • Show
Clear All
new posts

  • Serious vCPU performance concern

    Oh thank god I found a VMWare forum.....

    Hi All

    I've done some playing around with new Win2008 virtual machine and found some serious concerns.

    The server is Dell T610. 16gig, 4 core, 8 logical, 2.4ghz XEON.
    ESXi 4.1.0
    The guest is 2008 64bit, with 2vCPU's

    I've been testing CPU performance using 7Zip on a 400meg file.
    Our server requirements have a particular need for single-thread performance, so I run 7Zip with only one thread.

    7zip takes 4:50 on the VM.
    For comparison, on a recent 2ghz, 4core server this process takes 4:00.

    Obviously a problem here.

    So I tried setting process affinity on the 7Zip.exe process.
    This time the compression only took 3:20. THREE MINUES TWENTY!!!
    Note that setting affinity on a physical machine makes no difference. (Just as fast, on or off)
    On both physical and virtual machines, when affinity is not set, you can see the process being thrown between all cores in taskman)

    There MUST be something wrong here??

    I have tried reserving full CPU, I've set scheduling affinity in ESX (to 0,2). And I've tried turning off Core Sharing.

    I understand that I can permantly set CPU affinity on desired processes, but that really shouldn't be necessary. I could also run a single cpu vm, but occaisionally there would be two single-threaded processes running, and I have 4 physical cores!!

    If 7zip is taking an extra 1:30, then no doubt that a bunch of things in the OS would also become slugish. I'm talking instant response things... things that CAN'T be multi-threaded. Things that might take 800ms instead of 500ms. Heck I'm concerned even multi-threaded stuff is suffering!

    Could anyone else vouch for this extreme performance degredation?

    Thanks for listening!
    Last edited by OzzieTech; 14th January 2011, 15:55. Reason: Clarity

  • #2
    Re: Serious vCPU performance concern

    How many test runs have you done? Are you able to reproduce the results on every test run? Any other workload on the host system? How does changing the compression source file size affect the results?



    • #3
      Re: Serious vCPU performance concern

      Thanks Von.

      OK new test: wsus setup 3.0.exe (an already compressed file, as opossed to the 400meg file I was using):
      2.4g vm, affinity cpu0: 37secs
      2.5g phys, no affinity: 43secs (older cpu)
      2.5g phys, affinity cpu0: 43secs again

      Edit: I forgot the no affinty vm result. here it is: 50secs
      *Note that in vSphere performance chart, the 'Total mhz' only hits ~1800. With affinity set, it hits the full 2400.

      Both OSes are 2008, 64bit, with 64bit 7Zip.

      Also we have a specialised application running on the server.
      I can't go into to much detail, but a particular process in the application is very slow. I can say that it is translating a document from one format to another, not a very big document, and it is very inefficient, badly written.
      It's performance is suffering with or without cpu affinity.
      Inhouse App document conversion:
      3.0g phys machine: 9secs (older cpu) (7zip:
      2.4g vm, affinity CPU0: 20secs
      2.4g vm, no affinity: 30secs !!

      Now that result is different to 7zip: 7zip with single core affinity is faster on the VM than the older physical CPU's.
      But this specialised app's process is slower than older physical CPU's with affinity set.... And three times slower when affinity is not set!

      Obviously it is using code that is less VM friendly (ridiculous amounts of IO perhaps?... like I said, its not great code)

      In our case, with the specialised app, VM's are probably a bad idea.
      But I would like to help the community, and work out why 7zip, and god knows what else, suffers so badly on a Virtual Machine!
      Like I said, if 7zip, without intervention, is running slow, then I can only presume that lots of other things, including the kernel, are also suffering.

      Last edited by OzzieTech; 15th January 2011, 03:21. Reason: Posted to quick