Sleep/Resume only reads writes at 20MB/Sec

B

BobTheDog

Member
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
 
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
 
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
 
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.
 
Gregorio said:
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.
Click to expand...

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.
 
BobTheDog said:
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
Click to expand...

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?
 
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
 
dev@parallels.com said:
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.
Click to expand...

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
 
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
 
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.
Click to expand...

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.

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

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.
 
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
 
BobTheDog said:
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.
Click to expand...

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?

BobTheDog said:
Thanks for all your help
Click to expand...

And thank you guys for a good information which helps to catch us bugs and make the product better!
 
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
 
BobTheDog said:
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
Click to expand...

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.
 
BobTheDog said:
Could we please, please have a setup option to say write to disk at full speed, maybe vm.suspendFlatOut :)
Andy
Click to expand...

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!
 
You must log in or register to reply here.
Back
Top