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
kenross
Contributor
Contributor

I've got exactly the same problem.  When I suspend my single VM, the problem goes away.

Reply
0 Kudos
csdibiase
Enthusiast
Enthusiast

I've had this issue occur a dozen or so times since upgrading to lion. Sometimes a 'killall Dock' would resolve the issue sometimes a reboot would. Definitely not 100% tied to VMware in my case but it did seem like there was some corilation there.

Thanks for posting the work around Steve, I always love to see developers engage the user comunity, espeically when intermittent and hard to reproduce problems occur.

Reply
0 Kudos
noglider
Contributor
Contributor

kenross and everyone else, the fix in this post, earlier in this thread, is very likely to work. Just try it. It worked for me. Thank you, Steve.

Tom Reingold

Tom Reingold Maplewood, NJ and New York, NY
Reply
0 Kudos
l0v3r
Contributor
Contributor

My experience on this problem, I'm able to replicate this in this way:

- I have a virtual machine open with XP

- start to install something on the host

- when the installer starts optimizing the system the new Dock try to add the new application icon to the Launcher

- in this moment both processes mds and Dock starts eating CPU and memory

- if I kill Dock and mds, new Dock and mds opens and starts eating CPU and memory again

- if I close Fusion than kill Dock, new Dock and mds opens but this time with normal CPU and memory usage

- I can now reopen Fusion

Seams that the problem has something to do with the new Laucher function of the Dock

Maybe these informations are helpful

l0v3r

Reply
0 Kudos
JDeitch
Contributor
Contributor

Steve's temporary fix is working for me as well.  Dock is behaving nicely since I implemented it.

-Jay

Reply
0 Kudos
Hendey
Contributor
Contributor

Steve,

I think you hit on what I was having problems with. I have only see the Dock issue once and it seamed to happen the first time Lion checked for updates. I called Apple and they had me reboot and reset the PRAM. I need to understand this better. I had them connect me with a senior tech anyway because the first tech had no idea if it would fix the problem. The senior tech was not sure either but both of them were very nice to work with.

I hope I don't see this again but at least I have a temp solution that seams to work.

Best,

Reply
0 Kudos
solisys
Contributor
Contributor

OK, so it's pretty clear to me that this an Apple issue.  Initially I was thinking my issue was with Vmware Fusion, simply because it made sense to me but after closely monitoring the Dock process again, I've come to the realization that it's a Apple issue, whether it is with Lion or the Dock process.  Although, I'm more inclined to believe that it is a Lion issue because this never happened before I upgraded my iMac to Lion, and I've had it for 3 years.  THis morning I came in and my 'Dock' process was at 9.37GB of real memory.  I noticed that the 'Inactive' memory in  the 'Activity Monitor' was showng nearly 7GB.  I started closing all of my applications, and I noticed the 'Free' (Activity Monitor - System Memory) counter started to climb gradually.  I left my Vmware for last, but after I shut it down the 'Free' memory counter climbed by 2GB, which is what my vm had allocated, so shutting down my VM released the memory as it should.  The Dock process climbed another GB in size instead of decreasing.  It just appears that Lion won't let it chew up more than 10GB, although I've seen it at 11GB before.  I didn't realize that I had the option of using a different Dock application so I give it a try, although I'm hesitant to do that.  I sure hope Apple gets this issue resolved quickly because I'm getting flashbacks of my days as a Windows user when I had to reboot my PC several times a week just to get some work done, which is why I changed to Mac in the first place.

Reply
0 Kudos
Marc_Bachmann
Contributor
Contributor

Hi Steve,

your suggestion worked for me too.

Dock is not using more CPU since I changed the vmx and added:

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

Thnx!

Reply
0 Kudos
docgoku
Contributor
Contributor

It's been about 2 hours here.  VMX edit is holding, keeping the dock cpu % down.

I'm running 10.7.2

Mid 2009 Mackbook Pro 2.26MHz

8GB RAM

2xSeagate Momentus XT 750GB HHHDs in RAID0.

Win7x64 VM

@johnmharte
Reply
0 Kudos
Shel007
Contributor
Contributor

Today I got around to looking into why in the world my Dock process was eating memory like a deranged beaver, sitting at over 3GB of real memory, and 17GB of Virtual Memory, and CPU usage was nuts.  A few googles and I came to these sort of threads. 

Rebooted.  Made the change suggested by Marc (and others), started the VM, and VMware Tools automatically reconfigured back.  I don't particular care to remove access to the host filesystem frankly.  I went next to changing the settings of the VM, turned off the 3D acceleration (I don't need it anyways), turned the Application Menu to Never show, and turned off all of the application defaults.  After several hours, memory for dock is sitting ~29MB and Virt of 36.2MB, but this problem takes time (days?) to kick-in.

OSX 10.7.2

Fusion 4.1.1

Several threads have suggested switching to Parallels was the solution, and I tried that when Fusion 3 began acting up in Lion, but the latest Parallels caused excessive idle load compared to Fusion, enough to destroy battery life by at least 50%.  Not good.

So, when is someone in VMware (or Apple) going to actually fix this?

-S

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee

Hi Shel007, and welcome to the VMware Communities!

If you added the line to the vmx file and it vanished later, it's likely that either your VM was suspended instead of being powered off, or VMware Fusion was still running while the change was made.  If that is the case, can you try again, being certain to power off the VM and close Fusion before editing the file?

That vmx option should be sufficient to prevent VMware Fusion from triggering the runaway Dock, but it is still possible for other applications on your host to trigger the same problem -- I believe that DropBox is one possibility, so if you are using that on your host, you might wish to disable it until Apple fixes the underlying issue.

Cheers,

--

Darius

Reply
0 Kudos
Shel007
Contributor
Contributor

I'm certain I made the change after a full shutdown.  Upon start of the VM, and login, the system complained about not being able to open the shared folders and then the VMtools said it needed to make changes and reboot (which turns back on the sharing setting).  But like I said, I prefer it to be on anyways.

I forgot to mention that I turned off Dropbox also (saw those suggestions as well).

-S

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee

Hi Shel007,

The option you should add to work around this issue (isolation.tools.hgfs.notify.enable = "FALSE") should not disable sharing.  It should only mean that your host won't be immediately made aware of file changes made by the guest in your shared folders -- with the above option, a Finder window on the host will no longer automatically refresh its view of a shared folder when the guest makes a change to a file.

Could I ask you to go through the process of changing the vmx file again and powering on the VM (including Tools complaining and requesting a reboot of the guest), then shut the VM down and attach the resulting vmware.log from inside the VM bundle to your next reply?  That might give us a hint as to what's going wrong.

Thanks,

--

Darius

Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

Hi there,

As Darius suggested please follow the settings that he kindly restated for you and as many have already done in response to my suggested workaround to fix the issue. We know the fix works as many users have confirmed this already.

The setting looks very similar to other settings so please pay very careful attention to the string to set.

This should not result in any disabling of the VMware sharing feature of file access between the Windows VM and the OS X host, or any reboot of the Windows VM.

My guess from the description given, what may have happened is that you set a similar setting  to false which disables the VMware sharing feature completely and with mirroring also enabled will prompt the tools to put a dialog to ask the user to log off. This is because registry changes are made when enabling or disabling the mirroring feature, and also occurs  if you enable or disable the sharing feature as a whole. This is not  quite a reboot but could be mistaken for such if you are not paying close attention and are doing other work.

So just make sure that you have powered off the Windows VM, closed Fusion, then edit the VM's VMX file with the stated setting which should not already exist in that file. Start everything back up and log on to Windows your mirroring and sharing should still be as before and files still accessible.

Thanks. Steve
Reply
0 Kudos
frogworth
Contributor
Contributor

OK, well while we're all spamming this thread, I might as well ask again whether there's any kind of fix in the works from Apple (or VMware I guess?)

The change notification feature is really essential for my workflows within my Windows VM. I used to make it work by accessing the Mac host's files through samba rather than through the VMware shared folders, but Apple pretty comprehensively broke smb sharing in Lion (among other things, logins are weird and keep on breaking, and smb frequently stops the laptop from sleeping when the screen is closed), so I can't go back to that.

So unfortunately my preference is leave the setting on, and just restart VMware Fusion (and Dropbox) whenever the Dock starts going mad (every few days). Obviously this isn't a very good situation to be in.

Reply
0 Kudos
steve_goddard
VMware Employee
VMware Employee

Yes I am working on it, can't say more than that right now.

Thanks. Steve
Reply
0 Kudos
frogworth
Contributor
Contributor

Thanks Steve, your dedication is much appreciated.

Reply
0 Kudos
Shel007
Contributor
Contributor

Indeed there are three suggestions out there on the net:

Setting either

isolation.tools.hgfs.enable = "FALSE"

or

isolation.tools.hgfs.disable = "TRUE"

(Is one of the above total an error, or are there really two ways to set this same feature?)

Or setting

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

Apologies for not being precise, I set:

isolation.tools.hgfs.enable = "FALSE"

and commented out

# isolation.tools.hgfs.disable = "FALSE"

I went ahead shutdown the VM again, commented out my new addition, uncommented the original, restart Fusion and the VM.  The dialog box from VMware tools says roughly (shortened) "has modified settings to enable sharing data with the host.  You must log off to apply these settings. Press OK to logoff now...."

I have also read some suggestions to not use Unity mode.  That's a bummer of a suggestion, but I'll do anything to have my system memory back while this issue is sorted out.  We're all sort of grasping at lots of suggestions until someone (preferrably VMware) definitively (preferrably officially) states what is going wrong and what the correct actions are in the interim.

I will give the isolation.tools.hgfs.notify.enable = "FALSE" a try next.

Reply
0 Kudos
Shel007
Contributor
Contributor

Also, the KB article http://kb.vmware.com/selfservice/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=2011360... is not emcompassing enough if indeed it is fixing the same problem that has been plaguing many of us. 

CPU at 100% isn't the only indicator nor is it constant.  I have watch it run at 100% today for a bit of time, and see it turn around and drop back to normal again.  Memory growth by the Dock does seem to be consistent, but admittedly that can be a side affect of other program too, like the Dropbox mentions we've seen.  If anything, the CPU usage might be a direct relation to memory allocation or swapping, I just don't know what is happening to be more accurate.

At any rate, I'd suggest a revisit to give a few more indications.  I've added the changes to my VMX and will watch my system for any troubles over the next several days and will slowly turn back on features to help any watching the thread.

Cheers.

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee

Hi Shel007,

isolation.tools.hgfs.enable = "FALSE" is bogus.

isolation.tools.hgfs.disable = "TRUE" will completely disable shared folders.  You don't want to do this unless you really don't need to use shared folders at all.

isolation.tools.hgfs.notify.enable = "FALSE" will work around the problem by disabling the file-change notifications which are causing Dock to go insane.  As long as you haven't disabled Shared Folders yourself, the Shared Folders themselves should continue to work as usual except for the lack of file change notiifcations being passed to the host operating system.

Both Steve Goddard and myself are VMware employees (we have the "vm" logo underneath our avatar icons on the left of these posts), and Steve is the guru of Shared Folders, so if he says that you can fix this specific issue with that option, it's a fairly sure bet that he's right.  In fact, I am confident that if you were seeing Dock go crazy when you were running Fusion, and you've now added the required option to work around the problem, you can undo any and all other changes you made while trying to fix the problem, and you can then go back to using your virtual machine(s) as you normally would.  I'm not aware of any relation between Unity and this problem.

Cheers,

--

Darius

Reply
0 Kudos