chef-client extremely slow
Closed this issue · 2 comments
chef-client runs extremely slow, especially when syncing cookbooks. one item gets downloaded exactly every 5 seconds, almost as if there is some kind of timeout. DNS resolution works just fine in the VM. this behaviour happens against a local chef server and against the opscode hosted chef.
i have found a few references to this problem (specifically involving centos) but no solutions.
i built my own centos 6.5 using this base box: https://github.com/2creatives/vagrant-centos and i encounter the same problem, both when knife bootstrap'ng an instance and when building my own box where chef is installed with kickstarter.
when i use ubuntu (12.04) vagrant images it works fine against the local chef server and against the opscode hosted chef.
ok, managed to find a solution:
- rubygems/rubygems#513 (comment)
this did NOT fix it - hashicorp/vagrant#1172
this issue was spot on, basically:
sounds like the resolver on OSX (my host OS) isn't playing nice with IPv6 requests? i'll leave this issue open if you wanted to implement this or just close if not.
Sorry for the delay, and thanks for pointing this out. I had never been entirely sure how widespread this issue was, so I had been disabling the natdnsproxy1 feature in all my Vagrantfiles to fix this for our usage. But it's been a while since I've looked into this, and it does seem to be pretty widespread, so I've taken a shot at more properly fixing this for everyone in these base boxes. The newly released v20140311 boxes integrate the options single-request-reopen fix referenced here hashicorp/vagrant#1172 (comment). This is now part of the default /etc/resolve.conf file on the base boxes.
This approach seems to be working well for me, but let me know if these new boxes don't behave properly for you by default.