search

winnfsd / vagrant-winnfsd

Manage and adds support for NFS for Vagrant on Windows.
Other
570 stars 61 forks source link

winnfsd CPU load #106

Open jazzfog opened 7 years ago

jazzfog commented 7 years ago

Lately I started to notice that sometimes winnfsd process start to consume enormous amount of CPU - about 40%. Tried to analyze it with Sysinternals Process Explorer and Process Monitor but didn't find what does it do and why.

It was OK for last couple months since I started use it but this issue appeared 4 times over last week or two.

Has anyone seen something like this?

winnfsd

JakeTheSnake3p0 commented 7 years ago

I've had similar issues lately on one of my boxes, but I can't pin down exactly what's failing.

Here is the debug log for the plugin, though I don't think it'll be much help. When winnfsd.exe fails, it hangs around 25% CPU utilization +/- 2% indefinitely and no errors are logged to the cmd prompt.

...
[18:53:04] NFS READ \\?\D:\git-repositories\ruby\pos\db\migrate\20160712212803_a
dd_discountable_to_items.rb  OK
# It is at this point that the fail occurs.
# Everything below this line is written after `vagrant reload`
# without having closed winnfsd.exe
PORTMAP GETPORT 100003 2049
[18:58:00] NFS NULL OK
PORTMAP GETPORT 100005 1058
MOUNT NULL
MOUNT NULL
MOUNT Path D:/git-repositories/ruby with path alias /D/git-repositories/ruby alr
eady known
MNT from [redacted ip]
Final local requested path: \\?\D:\git-repositories\ruby

PORTMAP GETPORT 100003 2049
[18:58:00] NFS NULL OK
[18:58:00] NFS FSINFO \\?\D:\git-repositories\ruby  OK
[18:58:00] NFS PATHCONF \\?\D:\git-repositories\ruby  OK
...

Something to note:

If I don't close winnfsd.exe at all, it fails in increments of 25%.

  1. vagrant up
  2. Work with system, causing error and console lock (typing with no prompt or prompt response). CPU utilisation for winnfsd.exe now @ 25%.
  3. vagrant reload
  4. Repeat step 2 + 3, CPU utilisation now @ 50%
  5. Repeat step 2, CPU utilisation now @ 75%
  6. Close winnfsd.exe out of anxiety

There is no high CPU/memory usage on behalf of VirtualBox, it's just winnfsd that hangs. I can't speak to why, but the situations where I've encountered it are:

  1. When using bundle install/update; failed right after the last using [gem] console output, but never when calculating gem dependencies.
  2. When running bundle exec rails db:migrate RAILS_ENV=test at some point during the course of a ruby error (undefined method 'id' for nil:NilClass or some type of StandardError).

Using

-- UPDATE

I've also tried dropping my old vagrant box completely and use Ubuntu 16.04. I've completely done a fresh install of everything and the problems occur in the same places. I also tried using Ruby 2.3.1 (working previously) and the problem maintains.

The only observation I could provide is that this might be happening when there is simultaneous high CPU load and NFS file access. The issue is currently restricted to my Rails applications but maybe there's some sort of stress test out there I can run on one of my NFS exports from within Ubuntu?

JakeTheSnake3p0 commented 7 years ago

Turns out changing to UDP avoids the issue for me altogether; your mileage may vary. I also added noatime to the mount as it wasn't necessary for me to track last-accessed stats.

config.vm.synced_folder 'D:\git-repositories\ruby',
                          '/home/ubuntu/apps',
                          nfs: true,
                          mount_options: [
                            'vers=3',
                            :udp,
                            :nolock,
                            :noatime,
                            :rw
                          ]
jim5359 commented 5 years ago

UDP does not solve the problem for me. I still get high CPU loads occasionally. Often times when doing Git operations which involves a large number of modified files, such as a git checkout.