VMware Communities
vandaveer
Contributor
Contributor

Lion update 10.7.2 - Dock eating memory and CPU

I updated to OSX 10.7.2 yesterday. Since then, if I launch two VM at the same time, and ONLY then, the Dock will start eating CPU and memory. The memory usage will keep climbing until it takes every last available amount of memory. The system will come to a complete crawl. Killing Dock causes it to relaunch of course and then it starts all over. It does give me a temporary reprieve however until it can reach max available memory. I'm running on a MBP with 8 GB of RAM, a hybrid SSD main HD, and my VM's off of a secondary HD in the optibay. I'm wondering if anyone else is seeing this issue or has a solution?

Reply
0 Kudos
151 Replies
jcon
Contributor
Contributor

Disabling Shared folders seems to have helped me, no problems today.

Reply
0 Kudos
hobbes444
Contributor
Contributor

Hello,

here some support logs. I have only one VM, it was running since at least one hour, probably 2. I can’t tell exactly when the Dock process started running crazy.

I observed that the mds process is also eating up a lot of CPU at the same time, every time. But not as much.

Cheers

Reply
0 Kudos
AdrielH
Contributor
Contributor

Turned off shared folders yesterday, and haven't had a runaway dock since! Smiley Happy

Reply
0 Kudos
Arlo515
Contributor
Contributor

It sounds like this is the cause...heopfully they can fix the issue, I for one, depend on shared folders.

Reply
0 Kudos
arjunrc
Contributor
Contributor

Oh boy, I'm glad I found this thread.

The dock has reguarly been taking up close to 6GB of memory pretty much every day making my computer completely unusable.

I thought the OS was bonked. You are correct, upon not using VMware Fusion, I don't have that problem at all.

Not using Shared folders is not an option for me at all. I need it to share my desktop as well as folders with windows - my work environment is split between both platforms, so disabling it will make it useless for me. I have temporarily switched to VirtualBox till VMWare fixes this.

VMWare support: please do fix this urgently!

thx

Reply
0 Kudos
dk91
Contributor
Contributor

I have the same problem, I have 16GB ram, 2011 MBP, but it maxes out CPU up to a point, that after 48 hours it crashes the VMs!

VMware, please fix ASAP! - thanks

Reply
0 Kudos
AdrielH
Contributor
Contributor

arjunrc, it's not quite as convenient, but you can turn on File Sharing on the mac and mount the share from inside Windows, or turn sharing on in Windows and mount the share from the Mac. Works like a charm.

Reply
0 Kudos
arjunrc
Contributor
Contributor

Thanks Adriel - yes, like you mentioned, that works but takes me back to the Virtual Box days of sharing.

This seamless integration is extremely important to me, so I just went ahead and bought parallels last night (they have a $30 price for VMWare fusion owners 🙂 ). I think I am going to keep both - if one bombs I'll use the other. I've now moved to parallels and haven't noticed any such issues (yet) and its blazing fast (so far).

regds

arjun

Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

For anyone who can reproduce this,

I am a developer on the VMware Shared Folders feature, and sorry for the slow response in getting to this.

Please could someone enable the Shared Folders sharing again for the Windows VM and then suspend or shutdown the VM.

Quit Fusion and then edit the vmx file for the VM and add the following line if does not already exist (which it should not):

isolation.tools.hgfs.notify.enable = "FALSE"

(The file resides in the same folder along with all the files for the VM, is the same name as the name of the VM and ends with the extension ".vmx".)

Restart Fusion, restart the VM, ensuring that it has had a reboot if you suspened and didn't shut the VM down.

See if the problem reappears again.

From the descriptions that I have read, and system log events that occured, it seems that the directory change notification feature may be the cause of the issue. This feature monitors file system events on the host and notifies applications running in the VM, such as Windows Explorer so they can refresh their cached information of directory contents automatically. We poll the fsevents for this and Apple may have changed this and caused the feature to break.

Since it has not been reproduced in house so far from what I can tell, disabling this feature would help us narrow down the cause and maybe discover what Apple have changed.

Thanks. Steve
Reply
0 Kudos
Arlo515
Contributor
Contributor

Steve -

My vmx file has this line: isolation.tools.hgfs.disable = "TRUE"

This is pretty similar to the line you asked to add, so wasn't sure if it mattered.

To others: please note that the vmx file is inside the virtual machine package; you have to right-click "show package contents" to reveal it.

Reply
0 Kudos
nick2000
Contributor
Contributor

I have the dock problem too and am using shared folder. I will add the line in my vmx file as soon as I can shut down the VM.

Arlo, your line is related but not the same thing. The line that was given applies to notification.

Nick

Reply
0 Kudos
oxjox
Contributor
Contributor

Is it possible to test this out if you're using your bootcamp partition?

Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

The line you  have listed:
> My vmx file has this line: isolation.tools.hgfs.disable = "TRUE"

is for the shared folders feature and since the disable is set to true means that for your VM it is disabled. Changing it to FALSE would enable the VMware Shared Folders feature again. However, it must be done while the VM is not loaded or running. Really it is simpler to just use the Fusion UI to enable and disable the feature.

As Nick already stated that does not apply to the particular file system feature for notification to of updates to folder contents which I am wondering if is the issue here.

Thanks. Steve
Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

It should be fine to use a boot camp partition running as a VM with the line I suggested added to the vmx file for it.

Thanks. Steve
Reply
0 Kudos
AdrielH
Contributor
Contributor

Steve,

I followed your directions and applied your requested change but within an hour the Dock was running amuck again. Just checked to make sure my .vmx file changes held, and it looks like they did, here's a snapshot of my .vmx file:

.encoding = "UTF-8"
displayName = "Windows 7 x64"
roamingVM.enabled = "FALSE"
isolation.tools.hgfs.notify.enable = "FALSE"
roamingVM.useBackgroundSync = "FALSE"

Note: There are two other nodes for encryption (which I won't post here).

Over the last two days, with folder sharing turned off, there have been no issues with the dock. Interestingly, in this case where the dock was going wild again, it tamed right back down as soon as the VM started the process of suspending - there isn't even a need to restart the dock. During the suspension is there a hook being withdrawn from the dock?

If it helps, this is running on a "MacBookPro6,2" with 8GB ram under system 10.7.2.

I'll give it another go, but it doens't look like this is the Holy Grail.

Reply
0 Kudos
vandaveer
Contributor
Contributor

After an hour or so of running my Win7 VM today my Dock started running wild again. I suspended and made the requested change. Unlike AdrielH, I had to kill my Dock after suspending my VM. The memory and CPU usage stayed abnormally high.

I will post again after I've had some time to observe the Dock process.

Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

Thanks for trying. It is good to know either way. It all helps trying to narrow things down.

Another thing we can try, is to watch the file IO going on. We can try from the Windows guest and maybe even on the OS X host.

Maybe something is repeatedly changing a file from the VM side over the VMware shared folder on the host which is causing the issue.

So you can download process monitor from http://technet.microsoft.com/en-us/sysinternals/bb896645 here and run it in the guest.

It is straight forward to install and run it as administrator and set it to monitor file IO. You can even filter for path names that contain vmware-host.

Anyway, when the issue occurs, if you can run it in the guest, monitor the file IO for a short while, then save it to a log file and send it to me or let me know where you put it and I can take a look. You won't need to monitor the registry, network or process activity for this. That should keep the quantity of data down.

If there isn't any file IO going on from the guest, I would be surprised but that might mean then the issue is contained with our server side talking to host file system. Again, though it is narrowing things down.

Thanks. Steve
Reply
0 Kudos
orthohin
Enthusiast
Enthusiast

                               

You could try the standard troubleshooting suggestions: http://www.macosxhints.com/article.php?story=2004011205473937 http://forums.osxfaq.com/viewtopic.php?t=7269  In particular, you should remove all startup items from the list under your user account in the Accounts preferences. Note that to stop these apps from starting up at login, you need to remove them completely from the list in the Accounts preferences

Never trust a computer you can't throw out a window
Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

I was also going to suggest fs_usage and/or dtruss to see if that helps and monitor the vmware-vmx process and the dock process.

Maybe able to give us some hints if it is really a file IO issue here.

See man pages for these

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dtruss.1m.html

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/fs_usage.1.html

Thanks.

Thanks. Steve
Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

Something the Apple devs have pointed out with the file system events, is that DropBox has been known to cause issues and slow downs like this.

So if that happens to be installed, it could be worth temporarily disabling/removing too.

Thanks. Steve
Reply
0 Kudos