Hey @bd808, do you have any suggestions as to how to diagnose what's happening when the problem shows up again?

High guest CPU utilization seems to be a not uncommon complaint against Virtualbox: https://www.google.com/?q=virtualbox+100%25+cpu

A Vagrant reload, in addition to remounting NFS, does a cold boot of the VM so it would reset literally everything related to the VM. If you want to test the NFS hypothesis, you can disable NFS sharing with vagrant config nfs_shares no followed by vagrant reload.

Related ticket. https://www.virtualbox.org/ticket/14137

If I disable nfs_shares how is it going to share folders? I'm guessing performance is going to be a lot worse.

I may try it out on a weekend when I don't have to work.

Thanks for the answer bd808

In T97988#1348534, @Jhernandez wrote:

If I disable nfs_shares how is it going to share folders? I'm guessing performance is going to be a lot worse.

When explicit NFS sharing is disabled Vagrant will fall back to configuring the default transport for the container in use. For VirtualBox the fallback is the built-in "shared folders" service. Testing has shown that NFS is a bit more performant than this default sharing solution which is why we made NFS the default configuration but the VM will be useable with native VirtualBox sharing.

I've since updated vagrant and everything else, re-provisioned, etc.

I've noticed vagrant is faster now than before (i hadn't updated the vagrant folder for months), and I haven't had again the 100% issues, but now VBoxHeadless is always at a sustained ~60% of CPU. I haven't seen those 250% spikes or 100% maintained cpu usage.

I've tried disabling nfs as @bd808 suggested above but I got 130% maintained cpu usage all the time. Re-enabling nfs gave me back a 60% maintained CPU usage.

This is making the laptop be like a frying pan on an oven...

Can't spot any weird activity on top, this is what it usually looks like (there is sometimes a 9% or 10% spike by a process but every 20 secs or so)

Have you tried a complete rebuild of the VM (vagrant destroy -f && vagrant up)? This will lose any state that is stored only in the VM (eg wiki content) but it ensures that the VM environment doesn't have any strange leftover mess from roles that you tried at some point and then removed or old bugs that have been fixed. I try to do this myself about once a month.

Short of that, audit your enabled roles and see if there are things that run extra processes that you can do without. Your htop shows elasticsearch running which can be a resource hog if you don't have a lot of cpu and ram to give over to the VM.

After a destroy -f and up and git-update instance seems to be stable at ~7% cpu usage.

I also upgraded to Yosemite by mistake yesterday... so I'm not sure if that's affected...

I've talked with @TheDJ over irc:

13:19 <thedj> joakino: that's a powersafe bug in vmware + nfs vagrant
13:20 <thedj> basically every time you suspend your mac, this will start happening
13:20 <joakino> thedj: is there any solution? i tried disabling nfs but cpu usage was even worse
13:20 <joakino> oh really
13:21 <thedj> lemme check.
13:22 <thedj> i remember i recently changed something to attempt to fix this, and i only now realize it's actually no longer happening...
13:24 <thedj> in Vagrantfile, i changed: root_share_options[:mount_options] = ['noatime','rsize=32767','wsize=32767','async']
13:24 <thedj> to root_share_options[:mount_options] = ['nolock','noatime','rsize=32767','wsize=32767','async']
13:24 <thedj> i'm not sure if i have been using vagrant less than before, or if it fixed it :)
13:26 <joakino> thedj: thanks, i'll try it out soon!
13:26 <joakino> i'll test also if it only happens after suspending

I'm going to keep an eye on cpu usage and make some tests suspending. If usage spikes I'll try the nolock change to the vagrantfile and will report back any findings.