Jira (PUP-5380) Slow catalog run after updating to puppet 3.7.5

[Christopher Price (JIRA)]

Title: Message Title

Christopher Price commented on PUP-5380   Re: Slow catalog run after updating to puppet 3.7.5 Assuming that, with the same number of JRubies, there is a noticeable performance difference between 3.7.4 and 3.7.5, then I think that pinning to a specific number of JRubies and not altering that variable, and using the git bisect approach would probably be very illustrative in terms of helping us figure out what to focus on. So, my recommendation would be to pick a number of JRubies that works well for you with 3.7.4 and then let's go with that as a starting point. From there, what you'd need to do would be: clone the puppet repo to some location on the master: git clone g...@github.com:puppetlabs/puppet.git check out the 3.7.4 tag: git checkout 3.7.4 stop puppet server In your puppetserver conf.d directory, there should be a file called 'os-settings.conf'. It should contain a setting called ruby-load-path, which points to some directory in site-ruby as the place to load the puppet ruby code. uninstall the puppet package and verify that the puppet ruby code no longer exists in the directory that you found from the ruby-load-path setting. Modify the os-settings.conf file to add the path to the lib directory from inside of your git clone. (You'll want to also leave the site-ruby path in the value of the setting, so that it can still find facter, etc., from that path.) Restart puppet server At this point if you do a quick run of your perf testing, hopefully you'll see exactly the same kinds of results that you've been seeing with the packaged version of Puppet 3.7.4. Assuming that all goes well then you can start the git bisect. That should look roughly like this: git bisect start git bisect good # 3.7.4 is good git bisect bad 3.7.5 From that point, git will do most of the work for you. It will check out an intermediate commit, and you'd need to restart puppetserver and run your tests to see if the perf issue was showing up or not. If the perf problem is there, then just run git bisect bad and restart the server and test again. If the perf problem is not there, then run git bisect good and restart the server and test again. After you repeat this enough times, git will just tell you "this is the SHA of the commit where the 'bad' started happening. Based on the list of commits in Puppet between 3.7.4 and 3.7.5, I'd expect this to take about 6 or 7 iterations to complete. If it's possible for you to do that I think it might greatly accelerate the process of us tracking this down on our side... so, I know it'll be a bit of a pain and totally understand if you're not able to do it. But if you can, that'd be awesome! Add Comment   This message was sent by Atlassian JIRA (v6.4.11#64026-sha1:78f6ec4) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.