Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Vagrant performance #62

Closed
nathanielks opened this issue Sep 26, 2014 · 8 comments
Closed

Improve Vagrant performance #62

nathanielks opened this issue Sep 26, 2014 · 8 comments

Comments

@nathanielks
Copy link
Contributor

G'day all!

I've been working on a client site and vagrant/virtualbox's performance has been terrible. Did some research and found some methods that have increased performance significantly. I made the changes suggested in this article and I'm not frustrated anymore. Shall we go and do likewise? The main caveat is this is limited to *nix installations, so this won't (entirely) be compatible with windows machines. System resources can be modified, but NFS won't work ( and is where most of the performance gains are found ).

Here's a gist of what our modified Vagrantfile would look like.

@swalkinshaw
Copy link
Member

Yeah, I thought about setting the cpus before as well so a PR for this is welcome.

@austinpray
Copy link
Contributor

give VM 1/4 system memory & access to all cpu cores on the host

A bit conflicted about this. Especially if you are working with a team. I have a beefy computer:

screenshot 2014-09-28 15 15 38

So my box is going to be running 8 cores and 4gb of memory. I feel I would be developing and a completely different environment with completely different constraints than someone with a macbook air or some other less beefy laptop.

Then again production is cached anyway. What do you guys think?

@swalkinshaw
Copy link
Member

Using all the cores you have is fairly standard. Although we may want to cap that 1/4 of memory at like 2GB. I do agree it's a little crazy to use 4GB of ram for a dev VM.

@nathanielks
Copy link
Contributor Author

If anything, that section could be commented out or something. At the very least, NFS will improve performance dramatically. Or people can change the values to something more appropriate per project. Or perhaps have default config files they could import? I have a 13" mbp, so 1/4 mem and all cpus is a base DO box. I know while I'm cranking things out, I don't like waiting on my development machine. I'd prefer to have faster results and then tweak later. Thoughts?—
Sent from Mailbox

On Sun, Sep 28, 2014 at 3:23 PM, Austin Pray notifications@github.com
wrote:

give VM 1/4 system memory & access to all cpu cores on the host
A bit conflicted about this. Especially if you are working with a team. I have a beefy computer:
screenshot 2014-09-28 15 15 38
So my box is going to be running 8 cores and 4gb of memory. I feel I would be developing and a completely different environment with completely different constraints than someone with a macbook air or some other less beefy laptop.

Then again production is cached anyway. What do you guys think?

Reply to this email directly or view it on GitHub:
#62 (comment)

@austinpray
Copy link
Contributor

Capping at 2GB or even 1GB is reasonable. My sites barely reach 1GB of usage. Why not just set a cap at 1GB without doing the platform specific math? That is a fairly beefy linode/DO box and more memory isn't going to make a wordpress site only using 512mb faster. The NFS and CPU will be nice performance enhancers.

AustinMacbookPro:bedrock-ansible austinpray$ vagrant ssh -c 'cat /proc/meminfo'
MemTotal:         501776 kB
MemFree:           56992 kB
...

@austinpray
Copy link
Contributor

Also using 4GB of ram for a dev vm for me is a no-go because I usually have other VMs running such as modern.ie and friends that take their fair share.

@nathanielks
Copy link
Contributor Author

I can get behind 1gb || 2gb cap. @swalkinshaw?

@swalkinshaw
Copy link
Member

See #66

Decided to just hardcode it since it's way simpler. Anyone can customize now but at least the setting is there to see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants