Very slow sites when running BOA from vagrant

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
lsolesen's picture

Running VirtualBox 4.2.4 on a MacOS Lion and the BOA instance has 2 GB of RAM and Barracuda 2.04.

I have created a VM with Barracuda setup. I followed these guidelines:

http://larsolesen.dk/node/358

I managed to mount the static directory for my users like this in the Vagrantfile.

  config.vm.share_folder "platforms-o1", "/data/disk/o1/static", "~/workspace/platforms-o1", :extra => "dmode=755,fmode=755,gid=100,uid=110"
  config.vm.share_folder "platforms-o2", "/data/disk/o2/static", "~/workspace/platforms-o2", :extra => "dmode=755,fmode=755,gid=100,uid=112"
  config.vm.share_folder "platforms-o3", "/data/disk/o3/static", "~/workspace/platforms-o3", :extra => "dmode=755,fmode=755,gid=100,uid=113"

The octopus aegir instances are quick an responsive when accessed through the browser. However, the sites themselves are really, really slow.

Here is an output of ressources used while loading the slow site:

top - 13:28:43 up  3:32,  2 users,  load average: 0.43, 0.17, 0.06
Tasks: 115 total,   1 running, 114 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.5%us, 20.9%sy,  0.0%ni, 61.6%id,  0.0%wa, 15.0%hi,  0.0%si,  0.0%st
Mem:   2057452k total,  1664684k used,   392768k free,   122316k buffers
Swap:  1101816k total,     1796k used,  1100020k free,   878832k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                              
31068 www-data  20   0  348m 180m  94m D   34  9.0   0:11.13 php-fpm                                                                              
1798 mysql     20   0  745m 237m  10m S    0 11.8   5:54.75 mysqld                                                                               
2221 redis     20   0 40280 3660  948 S    0  0.2   2:23.89 redis-server                                                                         
41501 vagrant   20   0 19236 1408 1060 R    0  0.1   0:00.03 top                                                                                  
41635 root      20   0  8280  628  524 S    0  0.0   0:00.01 sleep                                                                                
    1 root      20   0 23692 1872 1300 S    0  0.1   0:01.13 init                                                                                 
    2 root      20   0     0    0    0 S    0  0.0   0:00.01 kthreadd                                                                             
    3 root      RT   0     0    0    0 S    0  0.0   0:00.45 migration/0                                                                          
    4 root      20   0     0    0    0 S    0  0.0   0:00.74 ksoftirqd/0                                                                          
    5 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/0                                                                           
    6 root      RT   0     0    0    0 S    0  0.0   0:00.50 migration/1                                                                          
    7 root      20   0     0    0    0 S    0  0.0   0:00.51 ksoftirqd/1                                                                          
    8 root      RT   0     0    0    0 S    0  0.0   0:00.00 watchdog/1                                                                           
    9 root      20   0     0    0    0 S    0  0.0   0:00.74 events/0                                                                             
   10 root      20   0     0    0    0 S    0  0.0   0:00.57 events/1                                                                             
   11 root      20   0     0    0    0 S    0  0.0   0:00.00 cpuset                                                                               
   12 root      20   0     0    0    0 S    0  0.0   0:00.00 khelper                                                                              
   13 root      20   0     0    0    0 S    0  0.0   0:00.00 netns                                                                                
   14 root      20   0     0    0    0 S    0  0.0   0:00.00 async/mgr                                                                            
   15 root      20   0     0    0    0 S    0  0.0   0:00.00 pm                                                                                   
   17 root      20   0     0    0    0 S    0  0.0   0:00.03 sync_supers                                                                          
   18 root      20   0     0    0    0 S    0  0.0   0:00.04 bdi-default                                                                          
   19 root      20   0     0    0    0 S    0  0.0   0:00.00 kintegrityd/0                                                                        
   20 root      20   0     0    0    0 S    0  0.0   0:00.00 kintegrityd/1                                                                        
   21 root      20   0     0    0    0 S    0  0.0   0:00.06 kblockd/0                                                                            
   22 root      20   0     0    0    0 S    0  0.0   0:00.03 kblockd/1                                                                            
   23 root      20   0     0    0    0 S    0  0.0   0:00.00 kacpid                      

All the sites run correctly on my production server, so I suspect it has something to do with the VM not passing on the data quick enough.

One issue might be proper write permissions to files and private, as the permissions are like this:

Files directory

drwxr-xr-x 1 o2 users 1020 2012-11-21 11:48 files/

Private directory

drwxr-xr-x 1 o2 users 136 2012-11-30 10:13 config/
drwxr-xr-x 1 o2 users 102 2012-11-20 01:17 files/
drwxr-xr-x 1 o2 users 102 2012-11-29 22:39 temp/

Hower, I am not able to change it with:

chown o1:www-data directory

It seems that it is because of the way VirtualBox handles mounted drives. However, I wanted to be able to easily edit the code for my sites. That is why I mounted the static directory.

But I also tried with site which was not on a mounted drive, and it was also really slow while the web interface for the octopus instances works well.

Comments

Use NFS to mount shared folders

adrinux's picture

It's not entirely clear from your post how you are mounting the directories you're sharing. But afaik vagrant uses NFS by default, and it doesn't look like there is proper mapping of your host user uid/gid to the users in the VM.

I have just set up something similar with aegir/vmware using nfs mounts, but not BOA.

Is this not proper

lsolesen's picture

Is this not proper mapping?

config.vm.share_folder "platforms-o1", "/data/disk/o1/static", "~/workspace/platforms-o1", :extra => "dmode=755,fmode=755,gid=100,uid=110"
  config.vm.share_folder "platforms-o2", "/data/disk/o2/static", "~/workspace/platforms-o2", :extra => "dmode=755,fmode=755,gid=100,uid=112"
  config.vm.share_folder "platforms-o3", "/data/disk/o3/static", "~/workspace/platforms-o3", :extra => "dmode=755,fmode=755,gid=100,uid=113"

What was you solution for doing the mounts?

That's vagrantfile syntax,

adrinux's picture

That's vagrantfile syntax, I've no idea whether that's right or not, I'm not using vagrant. I assume that gets used to write to /etc/exports on the host and /etc/fstab on the guest vm, what does it write?

vboxfs versus NFS

xurizaemon's picture

That sounds like it could be slow network mounts, although it's unclear why this issue would then affect the site which isn't on a mounted drive.

It’s a long known issue that VirtualBox shared folder performance degrades quickly as the number of files in the shared folder increases. As a project reaches 1000+ files, doing simple things like running unit tests or even just running an app server can be many orders of magnitude slower than on a native filesystem (e.g. from 5 seconds to over 5 minutes).

:nfs => true is the flag you want to add to your share_folder lines to switch from VboxFS to NFS. I'd be interested to hear your results.

If my comments have helped you, please pay it forward!
Use issue queues to discuss module issues - this will help your questions assist others (including yourself!) in future.

NFS does speed things up, but

nlambert's picture

NFS does speed things up, but causes weird permission errors in the status report. Drupal can't write to the files directory.

I tried serving directly from the VM which worked well. I even ran security review to make sure everything was setup correctly. Then copied the files to the NFS shared folder, changed the conf and restarted apache. Drupal could no longer write to the files directory.

According to this, every user should be able to write to the NFS shared folder :

https://groups.google.com/d/msg/vagrant-up/-J3UEqYXveA/icRSrqpWWGkJ

Has anyone experienced this?

File permissions on host machine

scottrigby's picture

@nlambert I have experienced this when using Vagrant on a mac with NFS mounting onto the host machine. In that case what I had to do was give write permissions on the host machine (Mac), then the permissions on the guest machine (VM) would take properly. It;s odd behavior, but the problem and fix are reproducible.

I've never used NFS with

maxresnick's picture

I've never used NFS with Vagrant. I've used the VirtualBox FS sharing. I run a windows 7 VM at home with a 20GB+ of photos in syncd folder and I haven't had issues.

Then again I don't believe the read and write is happening as fast as it would with a code base so maybe it's a real issue in this use case. If you switch back the the synced folder it might be worth install topio on the VM and see if your maxing out when hitting a page hosted on the VM.

For permissions fixes i've used the config.vm.synced_folder settings and set apache to run as the user 'vagrant' such that reading and writing wasn't an issue.

Just my $.02

Write permission issues

rojosnow's picture

I'm running Ubuntu 12.04.5 LTS as the guest OS on a Mac OS X 10.9.4. The following worked for me:
- Using NFS: http://docs-v1.vagrantup.com/v1/docs/nfs.html
- Bumping my VM RAM to 2G.
- Adding skip-name-resolve to mysql my.cnf.
- Adding/changing a innodb value in my.cnf: innodb_buffer_pool_size = 1400M (70% of guest OS RAM).

Then, I had issues writing to the Drupal files directory from the guest OS.

As a fix, I decided to run Apache on the guest OS as the user of my host OS. All steps should be run on the guest OS from the terminal.
- Stop Apache: sudo service apache2 stop
- Get the UID of the host OS as displayed on the guest OS.
- cd to the Drupal files directory and type ls -Al. On the listing, your user will be all numbers and the group will most likely be dialout (or UID of 20 which is the staff group on the host OS).
- UID of my host OS was showing on the guest OS as 662709276.
- Type sudo useradd -u YOUR_GUEST_OS_UID YOUR_HOST_OS_USER. My code looked like sudo useradd -u 662709276 rojosnow
- Edit /etc/apache2/envvars to export APACHE_RUN_USER=YOUR_HOST_OS_USER. My code looked like export APACHE_RUN_USER=rojosnow.

If Apache was running, remove the lock file since it's probably owned by www-data: sudo rmdir /run/local/apache2.

Now, restart Apache: sudo service apache2 start.

Hope it helps someone.

BOA

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: