https://bugzilla.wikimedia.org/show_bug.cgi?id=70971
--- Comment #6 from Bryan Davis <[email protected]> --- Another debug run done with: $ TZ=UTC /usr/bin/ruby /usr/bin/puppet agent --onetime --verbose --no-daemonize --no-splay --debug --trace --evaltrace --noop 2>&1 | tee /tmp/puppet-noop.log This one shows the long pause where nothing is logged (which lines up with the massive number of stat calls in other runs) as happening between this block: ^[[0;32mInfo: Git::Clone[vagrant]: Starting to evaluate the resource^[[0m ^[[0;32mInfo: Git::Clone[vagrant]: Evaluated in 0.01 seconds^[[0m And this block: ^[[0;32mInfo: /Stage[main]/Labs_vagrant/File[/srv/vagrant]: Starting to evaluate the resource^[[0m ^[[0;32mInfo: /Stage[main]/Labs_vagrant/File[/srv/vagrant]: Evaluated in 0.00 seconds^[[0m This is potentially more revealing of what is going on. The File[/srv/vagrant] resource does a recursive chown on the directory where MWV has been checked out. It also requires Git::Clone['vagrant']. My new guess at what is happening is that under the hood puppet creates a separate file resource for each file that is found in the recursive directory search. Each of these in turn inherits the require constraint. As puppet augments it's DAG with these nodes each one tries to figure out if Git::Clone is a type which leads to the insane number of stat calls. I think there are a couple of things that could be done here (besides some upstream patches to be smarter about things in general), the require on the file could be switched to be a before on the clone. My guess is that will make a big difference in the number of stat calls. The other additional thing that could be done would be to change the recursive ownership management to an exec of a find command to switches the ownership of files under the target directory. Having seen what this seems to be doing I think that would actually end up being quite a bit faster than letting puppet make a ton of ruby objects (1 for each file?) and evaluate them in series. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
