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

NFS shares? #95

Closed
CormacBracken opened this issue Jul 10, 2013 · 14 comments
Closed

NFS shares? #95

CormacBracken opened this issue Jul 10, 2013 · 14 comments

Comments

@CormacBracken
Copy link

I'm running my vm on an admittedly underpowered laptop. On one fairly php-heavy page, the page timed out after 60s having loaded maybe 20% of the generated content. (the same page loads ok on a 512mb server. ).

After poking around with fpm settings without result, I looked into switching to NFS shares, and found a startling benchmark - 5+ minutes vs 14s (http://docs-v1.vagrantup.com/v1/docs/nfs.html). Sure enough, when I got NFS working, my page loaded in around 10s (on first hit).

Only problem with that is, vagrant doesn't like the owner/permissions currently set when VVV shares /srv/www. I didn't fully understand the issue, so I just deleted the owner and permission arguments, and it works so I'm going with that...

Is there a reason not to use NFS shares?

@TheLastCicada
Copy link
Contributor

NFS shares with Vagrant/VirtualBox are not supported in Windows, so in the interest of maximum compatibility, we went with the VirtualBox default shared folders. They are definitely lower performance than NFS, so if you are comfortable making the change to NFS on your install of VVV, I absolutely recommend it. However, we've not had much of an issue with the shared folder performance - for nearly all of our needs, they have been sufficient. It does seem to be worse on certain machines and configurations, and if you have the ability to do NFS, that is the best solution.

Out of curiosity, what operating system are you using?

@CormacBracken
Copy link
Author

I gather from this page
http://docs.vagrantup.com/v2/synced-folders/nfs.html that
"Vagrant will ignore your request for NFS synced folders on Windows." That
sounds like it's supposed to fail gracefully, but I haven't tested that.

The fiddly bit is not so much changing the vagrantfile, as ensuring the
relevant bits and pieces are installed on host and guest. I suppose that
goes into the pre- and post- wossname scripts. (For what it's worth,
generic NFS config instructions for ubuntu look scary but turn out to be
completely unnecessary as vagrant takes care of everything (with just a
sudo prompt at one point.))

My host os is ubuntu precise.

On Wed, Jul 10, 2013 at 7:14 AM, TheLastCicada notifications@github.comwrote:

NFS shares with Vagrant/VirtualBox are not supported in Windows, so in the
interest of maximum compatibility, we went with the VirtualBox default
shared folders. They are definitely lower performance than NFS, so if you
are comfortable making the change to NFS on your install of VVV, I
absolutely recommend it. However, we've not had much of an issue with the
shared folder performance - for nearly all of our needs, they have been
sufficient. It does seem to be worse on certain machines and
configurations, and if you have the ability to do NFS, that is the best
solution.

Out of curiosity, what operating system are you using?


Reply to this email directly or view it on GitHubhttps://github.com//issues/95#issuecomment-20720710
.

Cormac Bracken
RedHotLemon.com - web design and development

@jeremyfelt
Copy link
Member

Per the numbers here, it looks like it's worth going down this path again. I'm going to play around with NFS locally and see what happens. Would definitely like to hear from Windows users as well to make sure it fails gracefully.

@jeremyfelt
Copy link
Member

This conversation between @rmccue and @kurtpayne also makes me want to test VVV more thoroughly with and without NFS on OSX and compare numbers with a Windows box. I know the MBA will skew things due to its SSD drive, so it would be nice to test in OSX on non-SSD as well. We should find a way to benchmark things in the VVV environment a few different ways.

@jeremyfelt
Copy link
Member

And more data for this thread, as of hashicorp/vagrant@c0404e3 (due in 1.2.5 release), NFS is mounted with UDP which apparently makes things even faster.

@jeremyfelt
Copy link
Member

I did a quick enable of NFS by adding :nfs => true to this line and got...

There are errors in the configuration of this machine. Please fix the following errors and try again: vm: * Shared folder that have NFS enabled do no support owner/group attributes. Host path: www/

...which is interesting. We specifically set the file permissions the way they are so that file uploads and such all work as expected.

I removed the :owner => "www-data" line, started up with NFS, and did a before/after cURL request to see what the speeds were like.

On a 46MB file served via nginx, I was getting an average of 73mbps without NFS and an average of 200mbps with NFS.

Crazy speed increase, though I agree with @TheLastCicada in that performance has been just fine for local development already. Not sure if this would help us enough to be worth it.

Voting to leave it off in the main repository for now. If more testing is done and we find a compatible way for NFS to work with our file permission requirements, then the story could change.

@rmccue
Copy link

rmccue commented Jul 26, 2013

On a 46MB file served via nginx, I was getting an average of 73mbps without NFS and an average of 200mbps with NFS.

whistles That's more than I expected.

With regards to permissions, what about mounting the uploads directory via the standard shared folders mechanism separately?

@jeremyfelt
Copy link
Member

I enabled NFS on a few things for a bit in my local setup and strange things kept happening, especially with the database files. I think things are fast enough without it that we should hold on this for now.

@tnorthcutt
Copy link
Contributor

@jeremyfelt just checking in here to see if you're still satisfied with the performance of the default VirtualBox shared folders, or if it might be worth revisiting switching to NFS. This tweet from Yoast today and the linked post got me thinking about it.

@danielbachhuber
Copy link
Contributor

NFS is much faster, but can come with problems of its own

@jb510
Copy link
Contributor

jb510 commented Mar 9, 2014

Daniel/Jeremy - I'm fiddling with this (read through the Slaty WP stuff too, +1 the mac kernel check! ). Am I missing something where all of the shares need to be NFS or could we NFS share /www and leave the database share as is?

@gavinballard
Copy link

FWIW, I saw a huge performance improvement when implementing NFS shares as per https://coderwall.com/p/uaohzg.

VVV v1.1, VirtualBox v4.3.14, Vagrant v1.6.3, OS X 10.9.4 on a stock mid-2013 MBA.

@Kevinlearynet
Copy link

To add to what @jeremyfelt mentions about strange issues happening with database files, I found this explanation very helpful:

To get NFS permissions right, your users need to have the same UID and GUID on host and guest. It's pretty tricky to setup and you should not change it from the guest. Maybe you can change it on the host to make it writeable to mysql and make UID and GUID the same. Of course, the moment the host changes this won't work anymore.

StackOverflow answer

After a lot of digging I was able to get this running on my Macbook pro w/OS X El Capitan. I'm using a custom forked setup of VVV with the following synced_folder configuration:

# https://github.com/mitchellh/vagrant/issues/6360
config.nfs.verify_installed = false

config.ssh.forward_agent = true
config.vm.synced_folder "database/", "/srv/database", 
  :nfs => true

if File.exists?(File.join(vagrant_dir,'database/data/mysql_upgrade_info')) then
  config.vm.synced_folder "database/data/", "/var/lib/mysql", 
    :nfs => true, 
    :mount_options => ['rw', 'vers=3', 'tcp', 'fsc', 'actimeo=2']
end

@lock
Copy link

lock bot commented Feb 23, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked and limited conversation to collaborators Feb 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants