Long memory release time on suspend

[stonefishsoftwa]

I am getting a regular (but not consistent) issue when suspending a VM guest in VMworkstation 8 on my Dell laptop

The VM guest is suspending quickly, but the host machine becomes slow to respond to anything (slugish) for the next 10 minutes.

(Shutting down the VM guest results in normal operation of the host machine.)

Looking at the Task Manager, I can see a long gradual decrease in the use of memory - not a sudden drop as I'd expect - hense my title of "log memory release time".

If I attempt to shut down the host machine, it will log out (although a lot more slowly than normal) but then take 10 minutes to complete the "Shut Down".

Host Specification:

VMware Workstation 8.0.4 (7744019)

Dell Precision M4600

WIndows 7 Professional x64 SP1

Intel Core i7-2720QM (@2.20Ghz - 4 processors, 2 cores per processor)

12Gb RAM

250Gb HDD (62Gb spare of 222Gb available)

Guest Specification:

Windows 7 Ultimate x32 SP1

3Gb RAM

4 processors (2 processors, 2 cores per processor)

40Gb HDD (6Gb spare)

Unfortunately I don't have a log file for the situation at the moment - once I have one, I will upload it.

Please let me know what other information I can provide to help diagnostics (other than a log file)

One thing to note is that I have just dropped the guest memory from 3.5Gb to 3Gb after noticing in the properties of the guest that after being allocated 3.5Gb it stated "3Gb usable".  Maybe this will help, but I doubt it.

[stonefishsoftwa]

I now have a log file (which has been attached to this post) from the session I have just suspended.

The VM host and VM guest were started today.

The VM guest was a few hours later suspended (which was immediate and without problem) and the VM host was shut down (again immediately with no delay).

The VM host was then restarted a while later and the VM guest restored

After another couple of hours, the VM guest was suspended.

Although the VM guest was shut down (and the log file shows this) it has taken around 10 minutes for the VM host to start acting "normally" again.

During this 10 minute period, VMware Workstation 8 itself took around a minute to close, and all other applications were sluggish and unresponsive.

The change of memory allocation from 3.5GB to 3GB has (as I predicted) made no difference.

I'm hoping this is just a configuration issue - and that somebody here might be able to give me an idea of how to sort this.

Cheers,

Tom

[stonefishsoftwa]

I'm disappointed by the lack of response.

If I am asking in the wrong place, or in the wrong way, please let me know what I should be doing instead.

Cheers,

Tom

[stonefishsoftwa]

I'm stunned... is there seriously nobody who can help with this issue?

I have attached a screen shot of my task manager showing just how long it takes to release the memory...

[Johnrg]

*bump*

I'm having the same problem!

Anyone out there know of a solution?

[continuum]

There is no "known solution" for this.

Try
mainMem.writeZeros = "TRUE"
in your config.ini - that helped in my case

[stonefishsoftwa]

Thanks for getting back to us continuum.

Unfortunately the configuration update has not helped me - I am still getting the same issue.

Can I assume that as there is "no known solution", this is officially recognised as a bug in the system?

If so, is there any way that I can see the official bug report / tracking for the issue?

Cheers,

Tom

(Thank you Johnrg for bumping the thread - although I don't understand why you got a response, and I didn't)

[continuum]

Hi Tom

unfortunately there is a missmatch between what I consider as a known issue and what the folks from VMware Inc. regard as a known issue.

So I do not know whether this is recorded as a bug - I would surely rate it as one.

[stonefishsoftwa]

I have raised a support ticket, and they are currently looking into the situation - although they are having great difficulty replicating the problem in house, and are saying it's a "host" problem.  (However, they ARE still looking into it, they've not just put the blame on my shoulders!)

Suggestions so far (which haven't worked) are:

- drop the number of processors to 1, and the number of cores to 1

- uninstalling and reinstalling Workstation

They have also suggested moving the hardware compatibility up to 9, but I'm not willing to pay for an upgrade unless there is a guarantee this will be sorted - but I conceed that as they don't know what the problem is, they cannot guarantee such a thing.

My latest thinking on it is that of the 12Gb of RAM installed, only 4Gb are originally from Dell - we added the extra 8Gb using memory from Crucial.  I'm not sure whether that would make any difference (Crucial is normally pretty good) especially as no other software on the laptop shows these symptoms (but then no other software on the laptop uses the quantity of memory that Workstation does).

Johnrg - I would suggest that you raise a support ticket yourself, as obviously there aren't many of us who are having this issue, and the more people who report it means the higher chance they might figure it out.

Fingers crossed!

Cheers,

Tom

[continuum]

A few more things to check ...
in WS 8 the vmem file tends to fragment at a horrible rate - check with your defragmentation tool - very likely you have your vmem files in ten thousands of fragments

try with
mainmem.useNamedFile = "false"
("true" is the silent default)

> as obviously there aren't many of us who are having this issue,...

Hmm - I dont agree - this problem has been mentioned so often that I regard it as a known issue - and everybody who monitors this forum will know about this. You will find lots of posts about this issue

[stonefishsoftwa]

I defrag both the instance and the host machine at least once a month - the last time was only a week ago.

I will try the "mainmem.useNamedFile" config and let you know.

> Hmm - I dont agree - this problem has been mentioned so often  that I  regard it as a known issue - and everybody who monitors this  forum will  know about this. You will find lots of posts about this  issue

I'm obviously really bad at searching, because I did try looking for previous reports before starting this thread.

Cheers,

Tom

[continuum]

The vmem files fragment at such a rate that I would suggest to defragment them daily - if not more often

[stonefishsoftwa]

Hi continuum,

The fragmentation on the single drive within the instance is only at 3%, the framentation of the single drive on the host laptop is also only at 3%... and using the defrag utility in Workstation on the virtual disc complete almost instantaneously (under a second).

One thing I don't understand is that the size of the virtual disc file on the host is 34.3Gb in size (that's AFTER a compact through the Workstation utilities) but the drive in the instance is only 28.1Gb used (of the 40Gb capacity)

I have also tried the configuration setting you suggested, but unfortunately there was no obvious effect (neither positive or negative)

It's all starting to drive me to distration!

Cheers,

Tom

[continuum]

did you check the fragmentation of the vmem files ?

[stonefishsoftwa]

I honestly have no idea how I would check the fragementation of the .vmem file... unless you mean by checking the general fragementation of the drive as a whole (in which case, I still don't know how you'd tell on that individual file).

From what I've literally just read, with the new configuration of mainmem.useNamedFile = "false" placed into the config.ini file, I don't think the .vmem file should even be created, should it?

[stonefishsoftwa]

I eventually managed to work out how to defragment the file using the "vmware-vdiskmanager" command line utility.

(The defragementation and compact utilities via the Workstation GUI say they have "completed" in a fraction of a second, which make wonder what on earth they're going on about - especially when the command line takes about 20 minutes for each command.)

Still no luck.

Support has asked me to add mainMem.writeZeros = "TRUE" to the .vmx config file, which has not worked.

They have also asked me to drop the RAM to 1Gb... which I will try, but very reluctantly.

This is a working machine, and this instance is in constant use... dropping it to 1Gb is going to make it almost unusable

This is really starting to annoy me now.

[continuum]

> This is really starting to annoy me now.

You are not the only one - I just suspended a 2Gb RAM VM on a 8 Gb RAM host and had to wait 30 minutes until the suspend was done.

Here I use WS 9 for curiousity reasons - if I had to use it for serious work I would still run 6.5.4

[stonefishsoftwa]

So, what in essence you're saying is "forget it, it's a problem, they know about, but they're going to do nothing about it".

I sort of got that impression about VMware when I saw how many people  have asked for the hot-keys to be configurable (so that it's possible to  disable the suspend via hot-keys).

Although it makes me feel better that I'm not the only one... it really does amaze me they've not sorted this out, and claim they have never managed to replicate it "in house", to quote the support guy trying to help me.

Got to love companies who get too big too quickly - they forget who got them there in the first place.

[stonefishsoftwa]

I have been running 8.0.5 for the last week, and the suspend issue appears to have gone.

I cannot tell if this is in combination with any configuration settings I have still have set (as I've been trying to get to the bottom of the issue) but all I know is that I've not had the "running like treacle after suspend" issue since the upgrade.

Fingers crossed it stays that way