I too see this behavior - my workaround (to avoid waiting 3-5 minutes for the system to recover) is to go into (host) standby and then immediately resume. This seems to cause the flushing to occur much faster, at the full rate my disk drives can go. For a 1.6 gig guest, it takes about 10-20 seconds longer to go to standby and when I resume, I see that physical memory that was used by the VM is now also freed up (but has probably been moved to the disk cache).
Since I now run my VM on an SSD, I tend to do a shutdown instead of a suspend, since I don't want to write to the SSD disk that often. That also solves the problem.
Without going into the details of how the system handles memory mapped files such as the .vmem file, it appears that after vmplayer does a suspend, it then exits with all the modified pages of physical memory (backed by the .vmem file) still needing to be written to disk. It would appear that this flushing activity is not done all at once, rather, it occurs over a long period of time (a few minutes). This seems to be what is causing the thrashing. I see this especially if I try to copy the VM directory somewhere too quickly after suspending a VM.
However, if you go to (host) standby, it seems that windows will then push this modified memory to disk at a much higher (more efficient) rate. Perhaps it does much larger writes whereas otherwise only a few pages at a time get written otherwise.
If you do a VM shutdown, then the virtual memory need not be saved and the .vmem file is deleted. It's been many years since I wrote code that did that sort of file mapping in windows. There must be a way to free up a memory mapped modified file without having to flush it first. Thus after a shutdown (instead of suspend) all physical memory is freed up instantly and the system doesn't thrash.
On the other hand, I've always been a bit puzzled at what is going on when you exit a VM and it says it's saving state. It clearly isn't writing all of memory to the .vmem file, but is relying on the system to do so after the program exits. In addition, if you resume a suspended VM (before doing other things), it restores its state almost instantly, since most of the .vmem file is still in physical memory and need not be read back from disk.
How the virtual disks are managed is unknown to me. Perhaps they too are memory mapped and the same sort of thing is going on there too.
