Sleep/Resume only reads writes at 20MB/Sec

Discussion in 'Windows Virtual Machine' started by BobTheDog, Sep 1, 2010.

  1. BobTheDog

    BobTheDog Member

    Messages:
    44
    Hi Guys,

    This is beginning to upset me!

    When resuming or sleeping parallels only loads or saves the ram image at 20MB/sec.

    When the VMS are running they R/W to the disk perfectly.

    Is there a setting somewhere to stop parallels acting in this way?

    Thanks for any help

    Andy
     
  2. Gregorio

    Gregorio Bit poster

    Messages:
    7
    I've had the same problem, (BTW Parallels 6 doesn't fix it). My colleague called support about it, unforunately after much push back they *insist* it was a problem with his system. If you know anything about hardrives you know this is unlikely, *any* consumer grade HD will write > 20MB/s. I have this exact problem and it makes suspending a VM a huge pain. I've seen this on 15+ installs of Parallels across our entire company.

    The biggest adverse effect of this is that if you suspend your VM on a removable drive it takes a significant amount of time to completely suspend to disk. Parallels give NO indication of what's going on in the background, if you eject and/or unplug the drive the VM will most likely be corrupted.

    To Parallels Management:
    I'm on the IT steering committee at our company, if this forum post sees no replys or is "hidden" by a moderator I'm insisting on budgeting for VMware Fusion this quarter.

    TL;DR: Parallels actually suspends the VM in the background at a very slow rate (20 MB/s). If you host your VM on a removable drive it can become corrupted if you remove it too early.

    Greg
     
  3. BobTheDog

    BobTheDog Member

    Messages:
    44
    Hi Greg,

    Ah, I'm not alone then.

    It does it on my Mac Pro and my two macbook pros, so for me 3 out of 3 machines!

    Bloody annoying to say the least.

    Cheers

    Andy
     
  4. BobTheDog

    BobTheDog Member

    Messages:
    44
    You right, exactly the same in version 6!

    I can write from windows 7 in parallels to the Mac Pro raid 0 disk at around 260MB/Sec but suspending uses 20MB/Sec.
     
  5. Gregorio

    Gregorio Bit poster

    Messages:
    7
    Also if you suspend two vms at the same time, the write speed is exactly 40 MB/s
     
  6. BobTheDog

    BobTheDog Member

    Messages:
    44
    Gi Greg,

    I have placed a support call, I will let you know how it goes.

    Cheers

    Andy
     
  7. Gregorio

    Gregorio Bit poster

    Messages:
    7
  8. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    Gregorio, thanks a lot for explaining the real issue for you - now I see the problem and must admit that we missed the removable drive use case.
    Let me explain you how it works, why you see 20Mb/s and how to workaround it.

    1. How it works and why 20Mb/s:
    By default VM memory resides in a plain file and is mapped to Parallels VM process.
    When VM is suspended, Parallels just closes the file and MacOS should do the rest - write the file on the media.
    Unfortunately, MacOS doesn't do file writeback until real memory must be freed for some purpose.
    This is not so good since when some other application will need memory MacOS will have to do a slow file write to get the memory and thus overall system performance may feel slow a long time after VM suspend "finished".
    To remove this negative effect Parallels (and Fusion BTW as well) force writeback of the file on the disk.
    This works well, except for another unfortunate effect - system may feel slow due to heavy I/O for tenth of seconds (and user will have no clue of what is happening), so we limited I/O speed to ~20Mb/s to improve user experience.
    You are right for sure that this should not be done for removable media. I will schedule a fix for the next update.

    2. How to workaround (for PD6 only):
    Add "vm.mem_anonymous=1" to VM -> Configure -> Hardware -> Boot Order -> Boot flags and restart VM.
    This flag will make PD6 to save compressed suspend state which should improve performance on slow media (e.g. USB drive) and greatly improve cold resume time. In this mode suspend dialog won't complete also before real data is written. I guess this is what should be enabled as default mode on removable media. Your feedback on whether it helps your problem is greatly appreciated.
     
  9. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    Bob, while I see the problem for Gregorio (use of removable media), can you please elaborate why 20Mb/s is a problem in your case? Do you use removable VM storage as well?
     
  10. BobTheDog

    BobTheDog Member

    Messages:
    44
    1. Because the RAM is not freed and other processes connot use it.
    2. Because I close the VM down and then shut the machine down and it takes forever to shutdown as the file is being written!

    I just got this from support:

    Dear Andy,

    We got a reply from our development team. The speed of suspend is not under control of Parallels Desktop as it is controlled by Mac OS X.

    It is a MacOS X background async disk flushes which is activated on memory reclamation. Parallels Desktop does not control it. If this operation requires more memory, then MacOS X will flush it at full speed. In this situation, Mac OS X thinks that much memory is not required and flushes at 20 MB/s.

    So, as the issue is not related to Parallels Desktop, we are closing this request.
    If you have any questions, please, do not hesitate to contact us.

    Best Regards,
    --
    Andrey Polienko
    Team Leader
    Support Department
    Parallels


    And here is my reply:

    Hi Andrey,

    Thanks for the info but it is not correct.

    I can proved that when memory requests are made to the system the file is not flushed any quicker even when the machine is totally out of RAM and failing mallocs.

    Also when the machine is shutdown this speed is the same and you sit there waiting at the blue screen, I would say that your developers need to look at it again!

    Thanks

    Andy
     
  11. BobTheDog

    BobTheDog Member

    Messages:
    44
    Sorry only just read this.

    It is not the same answer I got from support who seemed to be saying that the mac OS was responsible for this speed.

    It is pretty annoying not just on removable media but also on shutdown of the machine. If for instance I have a VM using 8GB that I shutdown and then try to shutdown the machine I have to wait for this to be written at 20MB/sec on a machine that can do over 200MB/sec, 10 times longer!

    Also way on my laptop with 8GB I tend to swap between a 6GB windows 7 vm and a 4GB xp vm, so when I shut one down to start the other I have to wait bloody ages for the file to be written before starting the other one as the ram has not been released, the disk can manage 80MB/sec so I am waiting 4 times more.

    I am going to try your workaround on version 6, if it works I will be a very happy bunny.

    Thanks

    Andy
     
  12. BobTheDog

    BobTheDog Member

    Messages:
    44
    Well the time to suspend fully to disk for a 6GB Vm went down from just under 6 minutes to a minute and 15 seconds even though the disk write was slower at 15MB/sec.

    Also real memory seems to be freed much quicker.

    A nice improvement.

    Could we please, please have a setup option to say write to disk at full speed, maybe vm.suspendFlatOut :)

    Cheers

    Andy
     
  13. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    I will double check, but on shutdown it should happen at full speed as application exits and it's up to OS to write the file before shutdown.

    regarding 2nd issue - fully agree.

    sure, there will be some flag. I will give you to know its name. So you will be capable to select the best one for you - compressed suspend states or full speed write of raw state.
     
  14. BobTheDog

    BobTheDog Member

    Messages:
    44
    Hi,

    Thanks that sounds great.

    I definitely see a very slow shutdown while a suspend is going on, this is one of the reasons I first started trying to work out what was going on.

    Thanks for all your help

    Andy
     
  15. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    Well, if you have 6Gb VM and 100Mb/s write speed it should take ~60secs for your host to shutdown. Is this what you observe? Or you have 6minutes instead?

    And thank you guys for a good information which helps to catch us bugs and make the product better!
     
  16. BobTheDog

    BobTheDog Member

    Messages:
    44
    Hi,

    My main machine has around 200-240MB/sec write on a raid 0 disk system. With a 8GB windows 7 VM it takes over 5 minutes I would say.

    With the flag you gave us though it should be down to a minute, I will do some testing and get back to you.

    Cheers

    Andy
     
  17. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    Bob,

    We've also resolved why that was the answer from the support. It's all my fault - there was a complaint long ago on similar issue, but where the customer did not provide a clue what bothers him in reality. So my answer was that it's up to MacOS to reclaim the memory and write it on disk (20Mb/s is what Parallels do to help MacOS to flush data faster). So after you guys provided a bit more information it became possible to find out what the real problem for people is.
     
  18. dev@parallels.com

    dev@parallels.com Parallels Developers

    Messages:
    54
    Andy, there will be vm.mem_flush_limit=0 boot flag in official update later (in Mb/s) to avoid 20Mb/s flush rate.
    It will be applied also automatically if VM resides on removable media (net/USB).

    vm.mem_anonymous=1 will also have sense (compressed images were written with the same rate limit applied :( ), so combined together these 2 flags should result in ~10-20sec suspend/resume time in your case ;-) Hope you'll like it!
     
  19. BobTheDog

    BobTheDog Member

    Messages:
    44
    Hi,

    Sorry I missed this post before.

    This is great news, thanks very much.

    All the best

    Andy
     
  20. ro050408

    ro050408 Bit poster

    Messages:
    3
    Please click one of the Quick Reply icons in the posts above to activate Quick Reply.
     

Share This Page