@freekmurze Any chance the issue was related to Spotlight indexing drives after install. I had a similar issue with other VM (from Vaprobash) right after Yosemite install, but all was cool after the Spotlight index completed.

@freekmurze, was this an upgrade to Yosemite or a clean install? I had a similar issues upgrading from mavericks to beta to official release. After trying everything under the sun including every web fix I could find, minimizing the services of the OS, and wasting a weekend, I read an article that basically said a fresh install makes a ton of difference.

After the fresh install, and I mean remounting 3 pass formatting and everything. My system is blazing on Yosemite, no services disabled. The only thing I don't use is the Mail App. I use Airmail 2. Before I re-installed Mail was using tons of CPU and memory. It might not be an issue now, but I've gotten used to Airmail. I'm using homestead 2.0, and I'm not linux guru, I've got about 15 laravel projects provisioned running locally on my VM both 4.2 and 5.0, 14 using mysql databases (none of them are huge) and its pretty zippy. It's been extremely fast since installing homestead 2.0 and I didn't need any settle time.

Also, I don't have any languages or scripting installed on my native system. Java to run PHP Storm and whatever comes with Yosemite out of the box, but I've install ruby, mcrypt and any other things i need on homestead.

Hope this helps, -Roni

I don´t know, maybe I also try that fresh installation thing, cause I´m always on beta releases. Its annoying to get the same messages over and over again.

After rebooting, the original problem is back... Really driving me nuts

In Activity Monitor I can find these statistics regarding the VBoxHeadless process

https://www.dropbox.com/s/dsda06gm88uah68/cpu.png

Does anybody know how to solve this slowness?

I also noticed that the Idle Wake Ups is very high

https://www.dropbox.com/s/apodrrt709kgql0/idle.png?dl=0

If anyone runs into this issue, I found the problem. It's hhvm causing the issue. For those not using hhvm, you can just stop the service by running vagrant ssh -c 'sudo service hhvm stop'.

I can verify that this only happens on fresh installs of vagrant/virtualbox on Yosemite.

Ok, something is weird here. Unfortunately I don't really have time to dig into this currently but I'll try to post an extensive follow-up within the next week. It's really starting to impede my work and the latest boxes aren't making this any better...

htop

The VM is provisioned to use all 8 cores, and 16GB of RAM (a quarter of my system); Yosemite 10.10.3. NFS enabled 64-bit, I/O APIC enabled. I am using file-vault to encrypt my user directory, and I will attempt again after moving the base outside of the encrypted container--I'm really hoping this isn't the case though, as I'm not using a ridiculous cipher... I realize it should be a bit slower but it's rather surprising just how terrible performance is on an 8-core Xeon.

Any thoughts? If someone wants to help me track this down forensically I will document a fix.

Also

Just FYI, that command right there (profiled with blackfire) is following best practices w/ very minimal compute time and db transactions processed in optimal chunks--this command runs in a few seconds on my server, but takes nearly 20 minutes on my homestead VM.

I am running into this too -- I have a very basic Craft site but response times are always 5+ seconds.

I'm willing to bet this is a swapping issue. Swapping will slow down any system, but in a VM it's orders of magnitude worse.

This should improve things considerably: SSH into the VM and execute:

sudo bash -c "echo 'vm.swappiness = 0' >> /etc/sysctl.conf"

Also, setting memory to 1/4 of your total system memory, and the full number of cpu cores you have in your homestead config (or altering the settings to those settings via the virtualbox gui for an already provisioned box) will also help.

These changes should give you a much more responsive virtual machine.

Same problem here. Tried everything, without result.

Switched to NFS synced directories a while ago and it fixed the problem then, but now it even occurs while using NFS.

So found out the problem on my instance. It had to do with queues.

Running artisan queue:listen with supervisor caused high VM cpu usage.

Solved it by using the artisan queue:work --daemon command instead. sudo supervisorctl reread + sudo supervisorctl update after the change to see improvement within a minute.

Thought I would resurrect this thread. Did anyone have any luck with a concrete answer on this? Homestead is basically unusable for us at this point.

Truthfully, I haven't started up homestead since valet came out. For all my current projects it's sufficient. However, it does look like homestead is continually being updated on github. https://github.com/laravel/homestead/graphs/contributors.

Perhaps posting specific questions there might help more than posting it on this thread. Which was more geared to yosemite.

@stueynet How do you access the local version of your site that's running on the VM? It's known that using the local url extension (www.app.local for instance) doesn't work well on a Mac because of interference with the Bonjour service and whatnot. Better to use anything other than that in your /etc/hosts, i.e. .dev.

So the solution to set the folder mounting as NFS fixed the slowness problem for me. Also it's correct that on mac if you use domain.local it will really slow things down. I now only use domain.dev.