vagrant up remains on 'Generate Drupal project with composer package'

[skorasaurus]

Issue Type

• Bug Report / Support Request

Your Environment

Vagrant 1.9.1
VirtualBox 5.1.22r115126
ansible 2.3.1.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.12 (default, Nov 19 2016, 06:48:10) [GCC 5.4.0 20160609]

Your OS

Ubuntu 16.04; 4.10.0-27-generic

Full console output

my sys log: https://gist.github.com/skorasaurus/1f9cea059d6e20dac3c2249d6945b09a

my Vbox log: https://gist.github.com/skorasaurus/e3117c413cb1c4d48520dedb6c64be86

my hardware
https://gist.github.com/skorasaurus/59c747f953182eb7ed98bd36947389eb

Summary

to reproduce on my system:
clone drupal-vm
git checkout 7c05f1f
vagrant plugin install vagrant-vbguest
cd drupal-vm
vagrant up

while issuing vagrant up for the first time after cloning the repository; there's no movement for more than 30 minutes at:
geerlingguy.drupal : Generate Drupal project with composer package
Compared to #1460 ;
My system does not crash and is still very responsive; I can use it for routine tasks, web browsing).

If I edit my config.yml to as cited at NFS shares are slow or hang due to UDP protocol, I am able to provision an environment after about 20 minutes.

Possibly related to #1468; there's no package named nfs-utils on my system; I do have nfs-common and nfs-kernel-server both at 1:1.2.8-9ubuntu12.1

[oxyc]

Great that TCP works! This is another + for #1468

Also related vagrant issue of tcp vs udp hashicorp/vagrant#2304

20min is still slightly slow but I guess that's because it's HDD rather than SSD.

Edit; yes, on Ubuntu nfs-utils is bundled as nfs-common

[oxyc]

@geerlingguy I guess we could improve the performance and fix some issues by running composer create-project in eg /tmp and then moving it to the correct location. I bet that would help with #1309 too.

[geerlingguy]

@oxyc - That sounds like a potentially good solution; hopefully it wouldn't introduce any other headaches though. Note that it might also make things slower if you're using native virtualbox synced folders (e.g. Windows)... If you can submit a PR, I could test at least on Ubuntu 16.04 once I get my laptop un-buried.

[oxyc]

Shouldn't it be faster with native vbox synced folders too? Im assuming a single mv, cp -r or rsync to the shared folder would be faster than running all the logic of composer create-project there.

[oxyc]

Also, by using either cp -r or the synchronize module we might not need to error out if the directory already exists. The operation could still theoretically be destructive if someone deleted the drupal/web/index.php file, and then changed a file that composer create-project scaffolds without committing to git. Thoughts?

This would avoid the very common issue that happens when you dont clear out the drupal/ directory. But still, maybe it's too easy to destroy sourcecode...

[oxyc]

Another thing I like about this idea is that the slow task wouldn't be Generating Drupal project anymore, instead something like Moving Drupal project files into place. That makes it both easier to debug and splits the longest task into two so the user can see that it's still working.

[oxyc]

On my macbook 12" 1.1ghz with SSD and NFS:

task	duration
composer create-project /tmp/drupal-project	49s
cp -r /tmp/drupal-project /var/www/drupalvm/drupal (udp)	48s
composer create-project /var/www/drupalvm/drupal (udp)	148s
composer create-project /var/www/drupalvm/drupal (tcp)	129s

That's quite a significant performance improvement to be honest.

As this would be added to the geerlingguy.drupal role but still easier to benchmark using Drupal VM I'll wait with opening up a PR for a bit I'll open up a temporary PR here for testing.

@geerlingguy let me know if you want me to open up a PR at geerlingguy.drupal.

@skorasaurus if you have the time, any chance you could test this and see if there's a noticeable performance improvement?

Edit: I added a benchmark for when TCP was used for the NFS share.

[skorasaurus]

Hi,

I just tested it as follows (let me know if I did not do this correctly):

git remote add oscar https://github.com/oxyc/drupal-vm.git
git fetch oscar
git checkout -b perf
git pull oscar perf
vagrant halt (I had my current drupal-vm still running)
vagrant destroy 
vagrant up (Started at 852)

(the general drupal project with comper package in /tmp/drupal-project started at 9:02)
finished at 9:05

Vagrant up finished in 13 minutes, nearly a 50% improvement :)

However, when I opened drupalvm.dev; the graphics did not display in chrome or firefox; see

Here's when I logged into the admin account in drupalvm.dev :

Refused to execute script from 'http://drupalvm.dev/' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Yesterday, drupalvm.dev loaded as expected.

(Side note, and sorry for side track): Although drupalvm.dev loaded successfully yesterday, I couldn't find my drupal install folder.I specified it in my config file but it was not there.

[oxyc]

The vagrant_synced_folders need to list two entries when you switch to nfsv4.

vagrant_synced_folders:
  # The default share.
  - local_path: ~/drupal/myvmsite
    destination: /var/www/drupalvm
    type: nfs
    create: true
    options_override:
      nfs_version: 4
      nfs_udp: false

  # Manually specify the /vagrant share to override the defaults
  - local_path: .
    destination: /vagrant
    type: nfs
    options_override:
      nfs_version: 4
      nfs_udp: false

The one that points to /var/www/drupalvm is the shared folder that is picked up at http://drupalvm.dev. As you want to edit the code on your host, and then sync it to where the Apache VirtualHost points, it's ofc required to have it shared.

The second that points to /vagrant is used primarily to get Drupal VM's provisioning/ directory to the VM when the user doesn't have ansible installed and everything is installed from within the VM, rather than from the host. The config.yml that you linked, only has this one which is why the install folder wasn't available on your host. @geerlingguy technically we could even drop this when ansible runs from the host?

Also @skorasaurus it might be worth checking if it works without specifying the NFS version, and just setting UDP to false.

vagrant_synced_folders:
  # The default share.
  - local_path: ~/drupal/myvmsite
    destination: /var/www/drupalvm
    type: nfs
    create: true
    options_override:
      nfs_udp: false

  # Manually specify the /vagrant share to override the defaults
  - local_path: .
    destination: /vagrant
    type: nfs
    options_override:
      nfs_udp: false

[oxyc]

@skorasaurus I updated my branch with a commit that defaults the nfs_udp to false. This should fix it without you having to edit vagrant_synced_folders at all.

[oxyc]

Derp I had a typo that broke it, just pushed another commit.

Also thanks so much for helping test all my ramblings! It really helps out

[skorasaurus]

@oxyc To clarify, what and how would you like me to test?

As I understand:

Do the following using this config

• vagrant halt (if I have my current drupal-vm still running)

• vagrant destroy

• vagrant up
  (measure the time it takes, report any errors in output, and check that drupalvm.dev is operating as expected)

and
repeat above with this 2nd config based on your most recent commit?

[oxyc]

@skorasaurus you could test:

1. vagrant halt
2. vagrant destroy
3. vagrant up

with this (if you have the most recent commit):

vagrant_synced_folders:
  # The default share.
  - local_path: ~/drupal/myvmsite
    destination: /var/www/drupalvm
    type: nfs
    create: true

It now defaults to TCP so it should work on all Linux distros, and even making it faster on at least my own macbook.

If if fails (but not otherwise) you can try:

vagrant_synced_folders:
  # The default share.
  - local_path: ~/drupal/myvmsite
    destination: /var/www/drupalvm
    type: nfs
    create: true
    options_override:
      nfs_version: 4

  # Manually specify the /vagrant share to override the defaults
  - local_path: .
    destination: /vagrant
    type: nfs
    options_override:
      nfs_version: 4

If UDP alone doesn't fix it, then we might have to specify the NFS version as 4. Sadly NFSv4 is not available on macOS so would be preferable if we could use the defaults from upstream Vagrant. But if there's no other choice, we probably need to add some logic that checks if the host OS is linux, and then set v4 if it is.

---

The other change in my branch is that the Drupal codebase is now built in /tmp and then moved over to /var/www/drupalvm/drupal rather than being built directly in the shared directory. On my own laptop this decreased the build task from 150s to 100s.

[skorasaurus]

Following the directions immediately above, with the first config that you provided, and received the following error: https://gist.github.com/skorasaurus/9addb87af6524e1cec753292a282d6aa

repeated directions again.
will try with the latter one momentarily; same result - https://gist.github.com/skorasaurus/f3b4fd2ca37348736d6cb03a2a13d080

[oxyc]

Hm @skorasaurus any chance you have ufw running on your host? #1204

http://docs.drupalvm.com/en/latest/getting-started/installation-linux/#mounting-nfs-shared-folders-hangs

[skorasaurus]

ufw is not running.

[skorasaurus]

Hi, I ran it once more again (rebooted my computer and I did vagrant destroy; i also did git clean -fd if it makes a difference); rebooted using the config at #1476 (comment) (the first one) and it worked!

Unfortunately, it had taken about 66 minutes during the initial vagrant up. (about 60 of those minutes were at TASK [geerlingguy.drupal : Move Drupal project files to drupal_composer_install_dir.] ***)

[oxyc]

Thanks! Good to know that it works at least.

This sounds more and more like the same issue as #1309.

That task that's slow only does this:

cp -r /tmp/drupal-project/. /var/www/drupalvm/drupal/ 

It should be reproducible within these commands:

vagrant ssh

composer create-project drupal-composer/drupal-project:8.x-dev /tmp/drupal --stability dev --no-interaction

cp -r /tmp/drupal/. /var/www/drupalvm/drupal/
# or any directory within the NFS synced `/var/www/drupalvm/`

Unfortunately as with #1309, I have no idea what could be causing such a slow cp task... :/

The thing you both have in common is that you're using Linux and a HDD rather than SSD. But that should really not account for a 60min cp task.

[oxyc]

I understand this must be getting frustrating. Besides switching to rsync I don't have many suggestions unfortunately.

What I would do is test if this also happens with a bare Vagrantfile:

Vagrant.configure('2') do |config|
  config.vm.box = 'geerlingguy/ubuntu1604'

  config.vm.network :private_network,
    ip: '192.168.88.87'

  config.vm.synced_folder '.', '/vagrant_data',
    type: 'nfs',
    nfs_udp: false
end

Installing composer manually within the VM:

sudo apt-get install php php-xml php-mbstring php-zip
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php -r "if (hash_file('SHA384', 'composer-setup.php') === '669656bab3166a7aff8a7506b8cb2d1c292f042046c5a994c43155c0be6190fa0355160742ab2e1c88d40d5be660b410') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"
php composer-setup.php
php -r "unlink('composer-setup.php');"

And then creating the project and copying to the NFS shared directory

php composer.phar create-project drupal-composer/drupal-project:8.x-dev /tmp/drupal --stability dev --no-interaction

time cp -r /tmp/drupal/. /vagrant_data/drupal/

If this is slow, maybe someone in the vagrant issue queue has ideas about what could be causing it. Or stackexchange as it might be more of an NFS issue. In my case the cp -r command takes 41 seconds.

[skorasaurus]

@oxyc

Thanks for your patience for following up so many times!

I did the first set of commands, listed below:

vagrant ssh

composer create-project drupal-composer/drupal-project:8.x-dev /tmp/drupal --stability dev --no-interaction

cp -r /tmp/drupal/. /var/www/drupalvm/drupal/ 

had taken 25 minutes for the cp command.
(and drupalvm.dev led me to http://drupalvm.dev/core/install.php ; not sure if that's intentional; but it's quite possible that my mucking around with settings.php at the moment could have done it).

My hard drive, I imagine, is relatively standard; for what it's worth, here's information about it (1tb; 7200RPM, sata) https://gist.github.com/skorasaurus/52a73578249a373d7a2ada5659afbf60

(FWIW, I do have my / and /home on separate partitions, both formatted as ext4 but that shouldn't be a problem).

[geerlingguy]

I'm hoping that the commit of the updated Drupal role will help with this. On my Mac, just as with @oxyc's testing, I noticed a marked improvement:

Before updating Drupal role:

real	8m7.036s
user	1m21.012s
sys	0m34.348s

After updating:

real	7m14.238s
user	1m18.963s
sys	0m35.378s

The 11% speedup here will likely be amplified on Windows or Linux where the share setup might not be as optimized...

[skorasaurus]

Thank you again for your effort and help.

I built (doing vagrant destroy, deleting my old drupal in rebooting my computer; git pull from @geerlingguy 's master and commit bc96336
My config file is this. Just to be sure, is this an okay config, right?

the 'vagrant up' had taken 45 minutes; definitely quicker than before 66 mins but obviously not the performance that we were looking and slower than when I did a cp in my ssh (#1476 (comment)).

I haven't tried @oxyc 's 2nd suggestion yet

[oxyc]

That's a correct config yes.

The 2nd suggestion you referred to would just be to try and determine that it's not Drupal VM related, and thus maybe asking in an issue queue with more knowledgable readers.

Something that might build the VM quicker is to run the composer create-project command on your host machine before provisoning. This would use the exact same config but instead of vagrant up:

1. cd to the root of your project (in your case ~/drupal/myvmsite)
2. composer create-project drupal-composer/drupal-project:8.x-dev drupal --stability dev --no-interaction
3. vagrant up

Doing that would make Drupal VM skip those tasks and maybe it's faster to sync from the host to the VM than vice versa.

[oxyc]

If the copy task alone takes 25min, 45min for the entire playbook doesnt sound unreasonable though. Maybe it's some NFS mount option that's needed or maybe it's just that HDDs are that much slower when it's NFS with these many files.

[geerlingguy]

If the copy task alone takes 25min, 45min for the entire playbook doesnt sound unreasonable though. Maybe it's some NFS mount option that's needed or maybe it's just that HDDs are that much slower when it's NFS with these many files.

HDDs, especially if you're running antivirus, or have some other types of background processes which require any kind of data access, are waaay slower than SSDs. So much so that I'd posit anything under an hour is pretty decent. I tend to forget just how bad it is not booting off/using an SSD, but consider that any time you're writing thousands of little Drupal files, if the disk needs to pause for a bit, move the heads to another place on the disk, and read a file for some other task, then come back to where it's writing drupal files... that's like magnitudes slower than an SSD.

Random access kills HDD performance. So if you absolutely can't use/upgrade to SSD, the secondary recommendation would be to at least have all your VMs / vagrant / virtualbox stuff on a second volume (not boot volume)/separate physical disk.