Guest OSes Slow - Sleep workaround...

Discussion in 'Installation and Configuration of Parallels Desktop' started by Zenkimoto, Dec 28, 2012.

  1. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    I have multiple guest OSes installed (Windows XP, Mac OS X, etc) and when I start either one of them, it is incredibly slow. I can barely do anything and it appears the CPU is churning. However, when I put my host system (Mountain Lion) to sleep, and go wake it up, it goes back to normal.

    This started happening after the last parallels update. I've read on the forums that the "sleep" is a work around. The other thing to do was to reinstall Parallels Desktop 8, which I did. It seemed to work the first few times and now it's back to the same. It's quite annoying to have to put my computer to sleep and wake it up in order use my guest OSes.

    Anyone experience this issue and know how to solve this or is this a Parallels bug?
     
  2. Andrew@Parallels

    Andrew@Parallels Parallels Team

    Messages:
    633
    Hi Zenkimoto,

    Could you please provide us with two report IDs:
    1. First report we need is when you just start your VM and observe system running slow;
    2. Second report is right after you put your Mac to sleep & wake it up

    Here is how you can submit the problem report (post the IDs here please): http://kb.parallels.com/9058
     
  3. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    Thank you Andrew. Here are the report IDs for before and after putting the Host OS (Mountain Lion) to sleep:

    Guest OS (Mountain Lion):
    Before: 20959267
    After: 20959309

    Guest OS (Windows XP)
    Before: 20961780
    After: 20961819

    As I stated, after I wake up the host OS, performance of the guest OS goes back to normal. At first I thought it was a guest OS specific issue, but since it happens on both Mac and Windows guest OSes, it doesn't appear so.
     
  4. Marquee

    Marquee Bit poster

    Messages:
    1
    Same issue here. Each time I restarted the guest OS (Windows XP), it is soooo slow. But if I restarted the host OS (Mountain Lion) even while the guest OS is starting, the performance of the guest OS goes back to normal.
     
  5. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    Hello Andrew,

    Should I put in a support request?

    Here are two other report IDs:

    Before putting Host OS to sleep: 21008398

    After waking up Host OS: 21008515
     
  6. Andrew@Parallels

    Andrew@Parallels Parallels Team

    Messages:
    633
    Hi Marquee,

    Can I have two problem report IDs from you please? Same as above.
     
  7. Andrew@Parallels

    Andrew@Parallels Parallels Team

    Messages:
    633
    Thanks, Zenkimoto! Give me some time please, I'll get back to you in a while.
     
  8. pborzenkov

    pborzenkov Junior Member

    Messages:
    19
    Zenkimoto,

    from these problem reports I can see that you are experiencing interrupt storm (e.g. your hardware sends a lot of interrupt requests to CPU) that disappears after sleep/wakeup sequence.

    To help us understand the problem more clearly please do the following:

    1) Download trace_intr tool from here: http://fe.parallels.com/6e3d0c6947b40d146b8cf02c03069173/trace_intr
    2) Make it executable (in Terminal.app):
    $ chmod +x ~/Downloads/trace_intr

    3) Make sure Parallels Desktop is not running and start the tool as following:
    $ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_wo_pd.log

    Type your user's password. Wait for ~30sec and type Ctrl-C to stop the tool

    4) Launch Parallels Desktop but do not start guest OS. Start the tool again:
    $ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_with_pd.log

    Wait for ~30sec and type Ctrl-C to stop the tool

    5) Start guest OS and launch the tool again:
    $ sudo ~/Downloads/trace_intr 1 > ~/Downloads/before_with_guest.log

    Wait for ~30sec and type Ctrl-C to stop the tool

    6) Put your Mac to sleep, wake it up and launch the tool again:
    $ sudo ~/Downloads/trace_intr 1 > ~/Downloads/after_with_guest.log

    Wait for ~30sec and type Ctrl-C to stop the tool

    You should have 4 log files in your Downloads folder at this point (before_wo_pd.log, before_with_pd.log, before_with_guest.log, after_with_guest.log). Please attach them to this thread.

    Thank you for your help!
     
  9. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    @pborzenkov

    I apologize that I did not see this response. It has been two months now... I just tried the link for the trace_intr tool but it doesn't seem to work. Can I get another link so I can diagnose the issue? I'm still putting my Macbook Pro every time I use parallels and it's getting pretty annoying at this point.

    Thanks for your help!!!
     
  10. pborzenkov

    pborzenkov Junior Member

    Messages:
    19
  11. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    @pborzenkov

    I seem to be having problems with the forum attachments. Every time I click on the "Manage Attachments" button, it gives me a blank screen (even on different browsers). Anyways, I have uploaded my Log files onto my server here: http://www.zenkimoto.com/Logs.zip

    If you guys get the forum fixed, I will upload my files here.

    Thanks!

    zenkimoto
     
  12. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    @pborzenkov

    I have uploaded additional log files onto my server here: http://www.zenkimoto.com/Logs2.zip It is my second test with the same above conditions.

    Thanks!

    zenkimoto
     
  13. pborzenkov

    pborzenkov Junior Member

    Messages:
    19
    Hi Zenkimoto,

    thanks for the logs.

    From these logs I can see that you have *a lot* of interrupt requests (about 550000 per second) on interrupt vector 52 even when Parallels Desktop is not running.
    This vector is shared between USB and SATA devices. We have already seen such problems with MacBook Pro 5,1 or 5,2 when CD-ROM was changed to SSD drive.
    From your original problem report I see that you did the same.

    This problem is not caused by Parallels Desktop software, but due to specifics of virtual machines functionality, those interrupt requests cost a lot more CPU time when
    virtual machine is running. That is why when VM is not running, you barely see the overhead of this interrupt storm, but when you start it, the CPU usage goes through the roof.

    You could try the following workaround from Parallels Desktop side: add 'vm.vcpu0bind=1' flag to boot flags of your VM: (Virtual Machine -> Configure -> Hardware -> Boot Order). This will bind virtual CPU0 to real CPU1. MacOS X processes interrupt requests on CPU0, so this flag should lower the CPU usage because VM will not deal with interrupt requests from hardware.

    Please post the results here.

    Thanks,
    Pavel
     
  14. Zenkimoto

    Zenkimoto Junior Member

    Messages:
    11
    Hi Pavel,

    Thank you so much for your help. You are absolutely correct. I replaced my DVD-ROM drive with another hard drive. I did not realize that this would cause interrupt problems.

    I have tried your workaround, however it crashes my system and gives me the "gray screen of death" kernel panic before it reboots. I don't think I will be doing that anymore.

    Anyways, I think I'll just resort to the putting my machine to sleep. It will have to do for now. Thank you very much for finding what the issue is. Unfortunately, I don't think I will be putting the DVD-ROM back in anytime soon.

    Thanks again,

    Zenkimoto
     
  15. skulaksiz

    skulaksiz Bit poster

    Messages:
    2
    Sorry to dig up an old thread, but I seem to have a similar problem and wanted to check if I have the same situation. I see that the trace_intr tool link expired after 30 days. Do you think you could post a new link? Thanks in advance!
     
  16. pborzenkov

    pborzenkov Junior Member

    Messages:
    19
    Hi skulaksiz,

    here is the link:

    http://fe.parallels.com/e37c0c5e7321d8d775131933f7e357f5/trace_intr
     
  17. skulaksiz

    skulaksiz Bit poster

    Messages:
    2
    Thank you very much for the quick response! It seems that my CPU0 is hammered (500000) by the com.apple.driver.AppleAHCIPort after a sleep/wake cycle (regardless of Parallels). The OS is on an SSD. Maybe this is the reason? Anyway, the rest of the machine runs fine (a little slow on the GUI side though) but Parallels really comes to a crawl after the sleep. It seems the following boot flag actually works:

    vm.vcpu0bind=1, vm.vcpu1bind=2

    Also just out of curiosity, any ideas why this happens in the first place?
     
    Last edited: Jul 30, 2013
  18. pborzenkov

    pborzenkov Junior Member

    Messages:
    19
    As I said before, this is the overhead of virtualization. Each interrupt request costs a lot more CPU time when VM is running. Normally, there are several thousands of these requests per second so you don't notice them. But when there are hundreds of thousands of these requests the CPU spends all the time dealing with them.

    It depends on which version of MacOS X you are using. If 10.8, then, unfortunately, the answer is no. Due to the changes in OS X kernel we can't bind VCPUs to physical CPUs anymore.

    If you are using 10.6 or 10.7, then yes, you can. Add these flags to boot flags of your VM (each on separate line):
    vm.vcpu0bind=1
    vm.vcpu1bind=2

    We investigated the problem with MacBookPro 5,1 and 5,2 and it looks like a bug in OS X drivers.
    The problematic interrupt vector is shared between AHCI (SATA) and USB devices. And whether the problem occurs or not
    depends on the order in which these drivers were loaded. That's why sleep/resume cycle helps sometimes (drivers could be re-loaded in different order).
     
  19. Peterwithes

    Peterwithes Junior Member

    Messages:
    14
    Interrupt storm workaround

    Just to help you with a workaround I'm using to avoid this problem: simply reboot you Mac resetting NVRAM (alt-cmd-PR). It works ever. You can use it every time you shut off the Mac; if you leave it in standby the storm does not appear.

    I also opened an issue with Apple, but they answer that this problem arise due to a unsupported HW config. They will not investigate about this bug; I'm quite sure that it's a bug with MacBook Pro releases 5,1 - 5,4. A friend of mine has a new MBPro with same HW config and this issue does not appear.
     

Share This Page